[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hao-trill-address-flush) 00 01 02 03 04

TRILL Working Group                                           Weiguo Hao
INTERNET-DRAFT                                           Donald Eastlake
Intended status: Proposed Standard                             Yizhou Li
                                                                  Huawei
                                                          Mohammed Umair
                                                                   Cisco
Expires: April 17, 2018                                 October 18, 2017


                      TRILL: Address Flush Message
                <draft-ietf-trill-address-flush-04.txt>


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 a 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........................................13
      2.2.5 Big Map of FGLs.....................................13
      2.2.6 All Data Labels.....................................14
      2.2.7 MAC Address List....................................14
      2.2.8 MAC Address Blocks..................................15

      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.  Section 6.2 of [RFC4762]
   is an example of the use of such a mechanism.

   Another example is based on Appendix A.3 of [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 message in this
   document could also be triggered in this case when one of the edge
   RBridges receives topology change information (e.g., TC in STP, TCN
   in MSTP) in order to rapidly flush the MAC addresses for specific
   VLANs learned at the other edge RBridge ports.

   A TRILL switch RB1 can easily flush any locally learned addresses it
   wants. This document specifies an RBridge Channel protocol [RFC7178]
   message to request flushing address information for specific VLANs or
   FGLs learned from decapsulating TRILL Data packets.



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.


W. Hao, et al                                                   [Page 4]


INTERNET-DRAFT                                     Address Flush Message


      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
         Management VLAN.

      RBridge - An alternative name for a TRILL switch.

      STP - Spanning Tree Protocol.

      TRILL switch - A device implementing the TRILL protocol [RFC6325]
         [RFC7780].





































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 and
   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 are 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.
   -  An Address Flush message can be sent selectively to the RBridges
      that have at least one access port configured as one of VLANs or
      FGLs specified in the Address Flush message payload.





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. 0x8946 is the Ethertype assigned by IEEE for the RBridge
   Channel protocol.

       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 Block 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


W. Hao, et al                                                   [Page 7]


INTERNET-DRAFT                                     Address Flush Message


         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.

      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. Thus, in the VLAN Block
         address flush case, K-VLBs will be at least one.

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

   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.


W. Hao, et al                                                   [Page 8]


INTERNET-DRAFT                                     Address Flush Message


   The extensible case is indicated by a zero in the byte shown in
   Figure 2 as "K-VLBs" followed by other information encoded as TLVs.

       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
         skips 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]

      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.

   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 message and TLVs are not required to be in any
   particular order.
      All RBridges implementing the Address Flush RBridge Channel
   message MUST implement types 1 and 2, the VLAN types, and type 6,
   which indicates addresses are to be flushed for all Data Labels.
      RBridges that implement FGL ingress/egress MUST implement types 3,
   4, and 5, the FGL types. (An RBridge that is merely FGL safe
   [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.)
      RBridges 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 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 accumulated
   from VLAN and/or FGL specifying TLVs in the message; and, if the MAC
   address TLV types are implemented, and a set of MAC addresses
   accumulated from MAC address specifying TLVs in the message.
   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 message. A


W. Hao, et al                                                  [Page 10]


INTERNET-DRAFT                                     Address Flush Message


   MAC addresses might be indicated more than once due to overlapping
   blocks or the like and a MAC address is included in the above set of
   MAC addresses if it occurs in any TLV in the address flush message.
      If the set of MAC addresses accumulated from parsing the address
   flush message is null, the 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 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 only to the set of
   Data Labels accumulated from parsing the message; if that set is
   null, the address flush message does nothing.

   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.



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:







W. Hao, et al                                                  [Page 11]


INTERNET-DRAFT                                     Address Flush Message


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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.
   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


W. Hao, et al                                                  [Page 12]


INTERNET-DRAFT                                     Address Flush Message


   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:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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


W. Hao, et al                                                  [Page 13]


INTERNET-DRAFT                                     Address Flush Message


   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:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type = 6      | Length = 0    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This type is used when a RBridge want 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 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.





W. Hao, et al                                                  [Page 14]


INTERNET-DRAFT                                     Address Flush Message


2.2.8 MAC Address Blocks

   If the TLV Type is 8, the value is a list of blocks of MAC addresses
   as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 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 itself provides no
   security assurances or features. However, Address Flush protocol
   messages can be secured by use of the RBridge Channel Header
   Extension [RFC7978]. It is RECOMMENDED that all RBridges that
   implement the 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.

   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 re-learned. 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.

   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, <http://www.rfc-
         editor.org/info/rfc7172>.

   [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, <http://www.rfc-editor.org/info/rfc7178>.

   [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,
         <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

   [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:

      Ramkumar Parameswaran, 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
      Cisco
      Cessna Business Park, Kadubeesanahalli Village, Hobli,
      Sarjapur, Varthur Main Road, Marathahalli,
      Bengaluru, Karnataka 560087 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) 2017 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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/