<?xml version='1.0' encoding='us-ascii'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<rfc submissionType="IETF" category="std" consensus="yes" number='8383'>
  <?rfc compact="yes"?>
	<?rfc text-list-symbols="-o*+"?>
	<?rfc subcompact="no"?>
	<?rfc sortrefs="yes"?>
	<?rfc symrefs="yes"?>
	<?rfc strict="yes"?>
	<?rfc toc="yes"?>
	<front>
	  <title abbrev="TRILL Address Flush Message">Transparent Interconnection of Lots of Links (TRILL): Address&nbsp;Flush&nbsp;Message</title>

	  <author fullname="Weiguo Hao" initials="W." surname="Hao">

	<organization abbrev="Huawei">Huawei Technologies</organization>
	<address><postal><street>101 Software Avenue,</street>
	<street>Nanjing 210012</street>
	<street>China</street>
	</postal>
	<phone>+86-25-56623144</phone>
	<email>haoweiguo@huawei.com</email>
	</address>
	  </author>
	  <author fullname="Donald Easlake 3rd" initials="D." surname="Eastlake, 3rd">
	    <organization abbrev="Huawei">Huawei Technologies</organization>
	    <address><postal><street>155 Beaver Street</street><street>Milford, MA 01757</street>
	    <street>United States of America</street></postal>
	    <phone>+1-508-333-2270</phone>
	    <email>d3e3e3@gmail.com</email>
	    </address>
	  </author>

	<author fullname="Yizhou Li" initials="Y." surname="Li">
	<organization abbrev="Huawei">Huawei Technologies</organization>
	<address><postal><street>101 Software Avenue,</street>
	<street>Nanjing 210012</street>
	<street>China</street>
	</postal>
	<phone>+86-25-56624629</phone>
	<email>liyizhou@huawei.com</email>
	</address>
	</author>

	<author fullname="Mohammed Umair" initials="M." surname="Umair">
	<organization>Cisco</organization>
	<address><postal><street>Cessna Business Park, Kadubeesanahalli Village, Hobli,</street>
	<street>Sarjapur, Varthur Main Road, Marathahalli,</street>
	<street>Bengaluru, Karnataka 560087</street>
	<street>India</street>
	</postal>
	<email>mohammed.umair2@gmail.com</email>
	</address>
	</author>

	<date month="May" year="2018"/>
	<workgroup>TRILL Working Group</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search.
-->

<keyword>example</keyword>

<abstract>
  <t> 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
	Media Access Control (MAC) addresses and the edge switch port of
	attachment from the receipt of local data frames and learns
	remote MAC addresses and the edge switch port of attachment from the
	decapsulation of remotely sourced TRILL Data packets.</t>

	<t>
   This document specifies a message by which a TRILL switch can
   explicitly request other TRILL switches to flush certain MAC
   reachability learned through the decapsulation of TRILL Data packets.

   <!--[rfced] To what does "the TRILL automatic address forgetting" refer?  Will the reader understand this phrase?

Original:
   This is a supplement to the TRILL automatic address forgetting and
   can assist in achieving more rapid convergence in case (see Section 4.8.3 of topology or
   configuration change.

-->
   This is a supplement to the TRILL automatic address forgetting <xref target="RFC6325"/>) and
   can assist in achieving more rapid convergence in case of topology or
   configuration change.</t>

	</abstract>
	</front>

	<middle>
	<section title="Introduction" anchor="section-1"><t>
   By default, edge TRILL (Transparent Interconnection of Lots of Links) switches
   <xref target="RFC6325"/> <xref target="RFC7780"/>, also called edge Routing Bridges (RBridges), 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 (FGL)
   <xref target="RFC7172"/>).</t>

	<t>
   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.  Section 6.2 of <xref target="RFC4762"/>
   is an example of the use of such a mechanism.</t>

	<t>
   Another example, based on Appendix A.3 of <xref target="RFC6325"/> ("Wiring Closet Topology"), presents a bridged LAN connected to a TRILL network via
   multiple RBridge ports. For optimum paths, Appendix A.3.3 suggests
   configuring the RBridge ports to be like one Spanning Tree Protocol
   (STP) tree root in the bridged LAN. The address flush Address Flush message in this
   document could also be triggered in this case when one of the edge
   RBridges receives Topology Change (TC) information (e.g., TC
   in STP, Topology Change Notification (TCN) in Multiple
   Spanning Tree Protocol (MSTP) in order to rapidly flush the MAC addresses
   for specific VLANs learned at the other edge RBridge ports.</t>

	<t>
   A TRILL switch can easily flush any locally learned addresses it
   wants. This document specifies an RBridge Channel Support protocol <xref
   target="RFC7178"/> message to request flushing address information
   for specific VLANs or FGLs (<xref target="RFC7172"/>) learned from decapsulating TRILL Data
   packets.</t>

   <section title="Terminology and Abbreviations" anchor="section-1.1">

     <t> 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 <xref target="RFC2119"/> <xref
	target="RFC8174"/> when, and only when, they appear in all
	capitals, as shown here.</t>

	<t>
   This document uses the terms and abbreviations defined in <xref
   target="RFC6325"/> and <xref target="RFC7978"/> as well as the
   following:</t>

	<t><list hangIndent="3" style="hanging"><t hangText="Data Label:">A VLAN or FGL</t>

         <t hangText="Edge TRILL Switch:">A TRILL switch attached to one or more links that provide end station service
	</t>

      <t hangText="FCS:">Frame Check Sequence</t>

      <t hangText="FGL:">Fine-Grained Label <xref target="RFC7172"/></t>

<t hangText="Management VLAN:"> A VLAN in which all TRILL switches in a campus
	indicate interest so that multi-destination TRILL Data packets,
         including RBridge Channel protocol messages <xref target="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
         Management VLAN.
	</t>

      <t hangText="MAC:">Media Access Control</t>

      <t hangText="RBridge:">An alternative name for a TRILL switch</t>

      <t hangText="STP:">Spanning Tree Protocol</t>

      <t hangText="TC:">Topology Change message</t>

      <t hangText="TCN:">Topology Change Notification message</t>

<t hangText="TRILL switch:">A device implementing the TRILL protocol RFC 6235
	<xref target="RFC7780"/>
	</t>

	</list>
	</t>

	</section>

	</section>

	<section title="Address Flush Message Details" anchor="section-2"><t>
   The Address Flush message is an RBridge Channel protocol message
   <xref target="RFC7178"/>.</t>

	<t>
   The general structure of an RBridge Channel packet on a link between
   TRILL switches is shown in <xref target="ref-rbridge-channel-protocol-message-structure"/>. The Protocol field in the
   RBridge Channel Header gives the type of RBridge Channel packet and
   indicates how to interpret the Channel Protocol Specific Channel-Protocol-Specific Payload

<!--[rfced] RFC 7178 does not use the specific term "Channel Protocol Specific Payload".  We note that RFC-to-be 8381 updated to use "Channel-Protocol-Specific Payload".  Please review the use of this term in this document and the other two and let us know if updates should be made.

-->
   <xref target="RFC7178"/>.
	</t>
<!--[rfced] We note that the content of Figure 1 is an exact replica
of Figure 1 in RFC-to-be 8381.  Only the titles are different.
Please confirm that this is intentional and no updates should be
made.

RFC 8381:
RBridge Channel Packet Structure

This document:
RBridge Channel Protocol Message Structure

-->

<figure title="RBridge Channel Protocol Message Structure" anchor="ref-rbridge-channel-protocol-message-structure"><artwork><![CDATA[

                   +-----------------------------------+
                   |            Link Header            |
                   +-----------------------------------+
                   |            TRILL Header           |
                   +-----------------------------------+
                   |      Inner Ethernet Addresses     |
                   +-----------------------------------+
                   |      Data Label (VLAN or FGL)     |
                   +-----------------------------------+
                   |       RBridge Channel Header      |
                   +-----------------------------------+
                   | Channel Protocol Specific Channel-Protocol-Specific Payload |
                   +-----------------------------------+
                   |   Link Trailer (FCS if Ethernet)  |
                   +-----------------------------------+
]]></artwork>
	</figure>

	<t>
   By default, an Address Flush RBridge Channel protocol message applies to
   addresses within the Data Label that appear 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. Both multi-destination and
   unicast Address Flush messages SHOULD be sent at priority 6 since
   they are important control messages but are lower priority than
   control messages that establish or maintain adjacency.</t>

	<t>
   Nevertheless:</t>

   <t><list style="symbols">

     <t>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.</t>

	<t>An Address Flush message can be sent unicast, if it is desired to
      clear addresses at one TRILL switch only.</t>

	<t>An Address Flush message can be sent selectively to the RBridges
      that have at least one access port configured as one of the VLANs or
      FGLs specified in the Address Flush message payload.</t>

	</list>
	</t>

	<t>
   Implementations should consider logging address flush Address Flush messages
   received with appropriate protections against packet storms.</t>

   <section title="VLAN Block Only Case" anchor="section-2.1">

     <t>
   <xref target="ref-address-flush-message-vlan-block-case"/> expands
   the RBridge Channel Header and Channel Protocol Specific Channel-Protocol-Specific Payload
   from <xref
   target="ref-rbridge-channel-protocol-message-structure"/> for the
   case of the VLAN-only-based Address Flush message. This form of the
   Address Flush message is optimized for flushing MAC addresses based
   on nickname and blocks of VLANs. 0x8946 is the Ethertype assigned
     by IEEE for the RBridge Channel protocol.</t>

<!--[rfced] Would a pointer to an IEEE registry be needed/wanted by the reader or others?  If so, please let us know how to update.

Original:
 0x8946 is the Ethertype assigned by IEEE for the RBridge Channel protocol

-->

	<figure title="Address Flush Message - VLAN Block Case" anchor="ref-address-flush-message-vlan-block-case"><artwork><![CDATA[
    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= 0x009|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          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       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   The fields in <xref target="ref-address-flush-message-vlan-block-case"/> related to the Address Flush message are as
   follows:</t>

	<t><list style="hanging" hangIndent="3">
	<t hangText="Channel Protocol:">
	The RBridge Channel Protocol value allocated
	for Address Flush (see <xref target="section-3"/>).
	</t>

	<t hangText="K-nicks:">The number of nicknames listed as an unsigned
	integer. If this is zero, the ingress nickname in the TRILL
         Header <xref target="RFC6325"/> is considered to be the only nickname to which
         the message applies. If non-zero, it gives 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
         listed. The message flushes address learning due to egressing
         TRILL Data packets that had an ingress nickname to which the
         message applies.
	</t>

	<t hangText="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 that some address
         learning is flushed that should not have been flushed, the
         network will still operate correctly; however, it will be less efficient
         as the incorrectly flushed learning is relearned.
	</t>

	<t hangText="K-VLBs:">The number of VLAN blocks present as an unsigned
	integer. If this byte is zero, the message is the more general
         format specified in <xref target="section-2.2"/>. If it is non-zero, it gives
         the number of blocks of VLANs present. Thus, in the VLAN Block
         address flush case, K-VLBs will be at least one.
	</t>

	<t hangText="RESV:">4 reserved bits. MUST be sent as zero and ignored on
	receipt.
	</t>

	<t hangText="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.  VLAN blocks may overlap, in which case, the address
         flush operation is applicable to a VLAN covered by any one or
         more of the blocks in the message.
	</t>

	</list>
	</t>

	<t>
   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 (i.e., from 0x001 to 0xFFE).</t>

	</section>

	<section title="Extensible Case" anchor="section-2.2"><t>
   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 is cumbersome. It also
   supports optionally specifying the MAC addresses to clear. This form
   is extensible.</t>

	<t>
   The extensible case is indicated by a zero in the byte shown in
   <xref target="ref-address-flush-message-vlan-block-case"/> as "K-VLBs" followed by other information encoded as TLVs.</t>

	<figure title="Address Flush Message - Extensible Case" anchor="ref-address-flush-message-extensible-case"><artwork><![CDATA[
    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=0x009 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Flags        |  ERR  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address Flush Protocol Specific:
   +-+-+-+-+-+-+-+-+
   | K-nicks       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Nickname 1                    | Nickname 2                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Nickname ...                  | Nickname K-nicks              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0             |  TLVs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
]]></artwork>
	</figure>

	<t><list style="hanging" hangIndent="3"><t hangText="Channel Protocol, K-nicks, Nickname:">These fields are as specified
	in <xref target="section-2.1"/>.
	</t>

	<t hangText="TLVs:">If the byte immediately before the TLVs field, which is the	byte labeled "K-VLBs" in <xref target="ref-address-flush-message-vlan-block-case"/>, is zero, as shown in <xref target="ref-address-flush-message-extensible-case"/>, the remainder of the message consists of TLVs encoded as
         shown in <xref target="ref-type-length-value"/>.
	</t>

	</list>
	</t>

	<figure title="Type, Length, Value" anchor="ref-type-length-value"><artwork><![CDATA[
          0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
         |  Type         |  Length       |  Value
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
	</figure>

	<t><list style="hanging" hangIndent="3"><t hangText="Type:">The 8-bit TLV type as shown in the table below. See
	subsections of <xref target="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
         skips to the next TLV by use of the Length byte. There is no
         provision for a list of VLAN ID TLVs as there are few enough of
         them that an arbitrary subset of VLAN IDs can be represented as
         a bit map.
	</t>

	</list>
	</t>

	<figure><artwork><![CDATA[
             Type       Description       Reference
            ------   ------------------  -----------------
                0     Reserved            [RFC8383]
                1     Blocks of VLANs     [RFC8383]
                2     Bit Map of VLANs    [RFC8383]
                3     Blocks of FGLs      [RFC8383]
                4     List of FGLs        [RFC8383]
                5     Bit Map of FGLs     [RFC8383]
                6     All Data Labels     [RFC8383]
                7     MAC Address List    [RFC8383]
                8     MAC Address Blocks  [RFC8383]
            9-254     Unassigned
              255     Reserved            [RFC8383]
]]></artwork>
	</figure>

	<t><list style="hanging" hangIndent="3"><t hangText="Length:">The 8-bit unsigned integer length in bytes of the
	remaining information in the TLV after the length Length byte. The
         length
         Length MUST NOT imply that the value extends beyond the end of the
         RBridge Channel Protocol Specific Channel-Protocol-Specific Payload area. If it does, the
         Address Flush message is corrupt and MUST be ignored.
	</t>

	</list>
	</t>

	<t><list hangIndent="3" style="hanging"><t hangText="Value:">Depends on the TLV type.</t>

	</list>
	</t>

	<t>
   In an extensible Address Flush message, when the TLVs are parsed,
   those TLVs having unknown types are ignored by the receiving RBridge.
   There may be multiple instances of TLVs with the same Type in the
   same address flush Address Flush message, and TLVs are not required to be in any
   particular order.</t>

	<t><list style="symbols"><t>All RBridges implementing the Address Flush RBridge Channel protocol
      message MUST implement types 1 and 2, the VLAN types, and type Type 6,
      which indicates addresses are to be flushed for all Data Labels.</t>

	<t>RBridges that implement the Address Flush message and implement
      FGL ingress/egress MUST implement types 3, 4, and 5, the FGL
      types. (An RBridge that is merely FGL safe <xref target="RFC7172"/>, but cannot
      egress FGL TRILL Data packets, SHOULD ignore the FGL types, as it
      will not learn any FGL-scoped MAC addresses from the data plane.)</t>

	<t>RBridges that implement the Address Flush message SHOULD implement
      types 7 and 8 so that specific MAC addresses can be flushed. If
      they do not, the effect will be to flush all MAC addresses for the
      indicated Data Labels, which may be inefficient as any MAC
      addresses not intended to be flushed will have to be relearned.</t>

	</list>
	</t>

	<t>
   The parsing of the TLVs by a receiving RBridge results in three pieces
   of information:</t>

	<t><list style="empty" hangIndent="3">
	<t><list style="numbers"><t>a flag indicating whether one or more Type 6 TLVs (All Data
         Labels) were encountered;</t>

	<t>a set of Data Labels accumulated from VLAN and/or FGL
         specifying TLVs in the message; and,</t>
<!--[rfced] This sentence does not seem to parse.  Please rephrase.

Original:
if the MAC address TLV types are implemented, and a set of MAC
addresses accumulated from MAC address specifying TLVs in the message.

-->

	<t>if the MAC address TLV types are implemented, and a set of MAC
         addresses accumulated from MAC address specifying MAC-address-specifying TLVs in the
         message.</t>

	</list>
	</t>

	</list>
	</t>

	<t>
   VLANs/FGLs might be indicated more than once due to overlapping
   blocks or the like, and a VLAN/FGL is included in the above set of
   VLANs/FGLs if it occurs in any TLV in the address flush Address Flush message. A
   MAC address might be indicated more than once due to overlapping
   blocks or the like, and a particular MAC address is included in the above set of
   MAC addresses if it occurs in any TLV in the address flush Address Flush message.</t>

	<t>
   After the above information has been accumulated by parsing the TLVs,
   three sets are derived as described below: a set of nicknames, a set
   of Data Labels, and a set of MAC addresses. The address flush
   operation at the receiver applies to the cross product of these
   derived sets. That is, a { Data Label, MAC address, nickname } triple
   is flushed if and only if the Data Label matches an element in the
   derived set of Data Labels, the MAC address matches an element in the
   derived set of MAC address, and the nickname matches an element in
   the derived set of nicknames. In the case of Data Labels and MAC
   addresses, a special value of the set, {ALL}, is permitted, which
   matches all values.</t>

   <figure><artwork><![CDATA[
   The sets are derived as follows:

      Data Labels set:
         If the Type 6 TLV has been encountered, the set is {ALL}, else,
         if any Data Labels have been accumulated by processing Data
            Label TLVs (Types 1, 2, 3, 4, and 5), the set is those
            accumulated Data Labels, else,
         the Data Labels set is null and the address flush Address Flush message does
            nothing.

      MAC Addresses set:
         In the receiver does not implement the MAC address types (Types
            7 and 8) or it does implement those types but no MAC
            addresses are accumulated in parsing the TLVs, then the MAC
            Address set is {ALL},
         else, the MAC Addresses set is the set of MAC addresses
            accumulated in processing the TLVs.

      Nicknames set:
         If the K-nicks field in the Address Flush message was zero,
            then the ingress nickname in the TRILL Header of the message
            is the sole nickname set member, else,
         the nicknames set members are the K-nicks nicknames listed in
            the Address Flush message.
]]></artwork>
	</figure>

	<t>
   The various formats below are provided for encoding efficiency. A
   block of values is most efficient when there are a number of
   consecutive values. A bit map is most efficient if there are
   scattered values within a limited range. And a list of single values
   is most efficient if there are widely scattered values.</t>

	<section title="Blocks of VLANs" anchor="section-2.2.1"><t>
   If the TLV Type is 1, the value is a list of blocks of VLANs as
   follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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 ...          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   The meaning of Start.VLAN and End.VLAN is as specified in <xref target="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
   discarded.</t>

	</section>

	<section title="Bit Map of VLANs" anchor="section-2.2.2"><t>If the TLV Type is 2, the value is a bit map of VLANs as follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 2      | Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   | RESV  | Start.VLAN            | Bits...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
	</figure>
	<t>
   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
   <xref target="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 discarded.
   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.</t>

	</section>

	<section title="Blocks of FGLs" anchor="section-2.2.3"><t>
   If the TLV Type is 3, the value is a list of blocks of FGLs as
   follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 3      | Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Start.FGL 1                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | End.FGL 1                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Start.FGL 2                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | End.FGL 2                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Start.FGL ...                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | End.FGL ...                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   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.</t>

	</section>

	<section title="list of FGLs" anchor="section-2.2.4"><t>If the TLV Type is 4, the value is a list of FGLs as follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 4      | Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | FGL 1                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | FGL 2                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | FGL ...                                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   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 Address Flush
   message MUST be discarded if the receiving RBridge implements Type 4.</t>

	</section>

	<section title="Big Map of FGLs" anchor="section-2.2.5"><t>If the TLV Type is 5, the value is a bit map of FGLs as follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 5      | Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Start.FGL                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Bits...
   +-+-+-+-+-+-+-+-
]]></artwork>
	</figure>
	<t>
   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 if type Type 5 is implemented.  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.</t>

	</section>

	<section title="All Data Labels" anchor="section-2.2.6"><t>If the TLV Type is 6, the value is null as follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 6      | Length = 0    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   This type is used when an RBridge wants to withdraw all addresses 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 discarded.</t>

	</section>

	<section title="MAC Address List" anchor="section-2.2.7"><t>
   If the TLV Type is 7, the value is a list of MAC addresses as
   follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 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                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   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 discarded if the receiving RBridge implements
   Type 7.</t>

	</section>

	<section title="MAC Address Blocks" anchor="section-2.2.8"><t>
   If the TLV Type is 8, the value is a list of blocks of MAC addresses
   as follows:</t>

	<figure><artwork><![CDATA[
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Type = 8      | 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                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	</figure>
	<t>
   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.</t>

	</section>

	</section>

	</section>

	<section title="IANA Considerations" anchor="section-3">

	<section title="Address Flush RBridge Channel Protocol Number" anchor="section-3.1"><t>
   IANA has assigned 0x009 as the Address Flush RBridge Channel
   Protocol number from the range of RBridge Channel protocols allocated
   by Standards Action <xref target="RFC7178"/> <xref target="RFC8126"/>.</t>

	<t>
   The added entry to the "RBridge Channel Protocols" registry at &lt;https://www.iana.org/assignments/trill-parameters/&gt; is as follows:</t>

	<figure><artwork><![CDATA[
      Protocol  Description       Reference
      --------  --------------    ------------------
        0x009    Address Flush     [RFC8383]
]]></artwork>
	</figure>
	</section>

	<section title="TRILL Address Flush TLV Types" anchor="section-3.2"><t>
   IANA has created the "TRILL Address Flush TLV Types" registry
   at  &lt;https://www.iana.org/assignments/trill-parameters/&gt; as a subregistry of the "RBridge Channel
   Protocols" registry.

   <!--[rfced] Please review our update to the description of the relationship between the "RBridge Channel Protocols" registry and the "TRILL Address Flush TLV Types" registry (i.e., please confirm that the latter is a subregistry).

-->
   Registry headers are as below. The initial
   entries are as in the table in <xref target="section-2.2"/>.</t>

<figure><artwork><![CDATA[
      Registry:  TRILL Address Flush TLV Types
      Registration Procedures: IETF Review
      Reference:  [RFC8383]
]]></artwork>
	</figure>

	</section>

	</section>

	<section title="Security Considerations" anchor="section-4"><t>
   The Address Flush RBridge Channel Protocol itself provides no
   security assurances or features. However, Address Flush protocol
   messages can be secured by use of the RBridge Channel Header
   Extension <xref target="RFC7978"/>. It is RECOMMENDED that all RBridges that
   implement the address flush Address Flush message be configured to ignore such
   messages unless they have been secured with an RBridge Channel Header
   Extension that meets local security policy.</t>

	<t>
   If RBridges receiving Address Flush messages do not require them to
   be at least authenticated, they are relatively easy to forge. In that
   case, such forged Address Flush messages can reduce network
   efficiency, by purging useful learned information that will have to
   be relearned. This provides a denial-of-service attack, but cannot
   cause incorrect operation in the sense that it cannot cause a frame
   to be improperly delivered.</t>

	<t>
   See <xref target="RFC7178"/> for general RBridge Channel Security Considerations.</t>

	<t>
   See <xref target="RFC6325"/> for general TRILL Security Considerations.</t>

	</section>
      </middle>
      <back>

	  <references title="Normative References">

	  <?rfc include="reference.RFC.2119"?>
	  <?rfc include="reference.RFC.6325"?>
	  <?rfc include="reference.RFC.7172"?>
	  <?rfc include="reference.RFC.7178"?>
	  <?rfc include="reference.RFC.7780"?>
	  <?rfc include="reference.RFC.7978"?>
	  <?rfc include="reference.RFC.8174"?>

	</references>

	<references title="Informative References">

	  <?rfc include="reference.RFC.4762"?>
	   <?rfc include="reference.RFC.8126"?>

	</references>

	<section title="Acknowledgements" numbered="no" anchor="acknowledgements"><t><list style="hanging" hangIndent="3"><t hangText="The following are thanked for their contributions:">
	<vspace blankLines="1"/>
	Ramkumar Parameswaran, Henning Rogge
	</t>

	</list>
      </t>

<!--[rfced] Throughout the text, the following terminology appears to be used inconsistently.

Please review these occurrences and let us know if/how they may be made
consistent.

RBridge Channel messages vs. RBridge Channel protocol message

Address Flush message vs. address flush messages vs. address flush Message

type # vs. Type # (e.g., type 6 vs. Type 6)

length bypte vs. Length byte

-->

	</section>

	</back>

	</rfc>