Skip to main content

TRILL: Address Flush Message
draft-ietf-trill-address-flush-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 8383.
Expired & archived
Authors Hao Weiguo , Donald E. Eastlake 3rd , Yizhou Li
Last updated 2016-11-25 (Latest revision 2016-05-24)
Replaces draft-hao-trill-address-flush
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd Susan Hares
IESG IESG state Became RFC 8383 (Proposed Standard)
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to "Susan Hares" <shares@ndzh.com>
draft-ietf-trill-address-flush-00
TRILL Working Group                                           Weiguo Hao
INTERNET-DRAFT                                           Donald Eastlake
Intended status: Proposed Standard                             Yizhou Li
                                                                  Huawei
Expires: November 23, 2015                                  May 24, 2016

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

Abstract

   The TRILL (TRansparent Interconnection of Lots of Links) protocol, by
   default, learns end station addresses from observing the data plane.
   This document specifies a message by which an originating TRILL
   switch can explicitly request other TRILL switches to flush certain
   MAC reachability learned through the egress 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 topoogy 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."

   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 1]
INTERNET-DRAFT                                     Address Flush Message

Table of Contents

      1. Introduction............................................3
      1.1 Terminology and Acronyms...............................3

      2. Address Flush Message Details...........................5
      2.1 VLAN Block Case........................................6
      2.2 Extensible Case........................................7

      3. IANA Considerations....................................11
      4. Security Considerations................................11

      Normative References......................................12
      Informative References....................................12
      Acknowledgements..........................................12

      Authors' Addresses........................................13

W. Hao, et al.                                                  [Page 2]
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 (see, for example,
   [TCaware] and Section 6.2 of [RFC4762]).

   A TRILL switch R1 can easily flush any locally learned addresses it
   wants. This document specifies an RBridge Channel protocol [RFC7178]
   message to request flushing address information learned from
   decapsulating at remote RBridges.

1.1 Terminology and Acronyms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   This document uses the terms and acronyms defined in [RFC6325] and
   [ChannelTunnel] as well as the following:

      Data Label - VLAN or FGL.

      Edge TRILL switch - A TRILL switch attached to one or more links
         that provide end station service.

      FGL - Fine Grained Label [RFC7172].

      Management VLAN - A VLAN in which all TRILL switches in a campus
         indicate interest so that multi-destinaiton TRILL Data packets,
         including RBridge Channel messages [ChannelTunnel], 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.

W. Hao, et al.                                                  [Page 3]
INTERNET-DRAFT                                     Address Flush Message

      RBridge - A alterntive name for a TRILL switch.

      TRILL switch - A device implementing the TRILL protocol.

W. Hao, et al.                                                  [Page 4]
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 type of RBridge
   Channel packet is given by the Protocol field in the RBridge Channel
   Header that indicates how to interpret the Channel Protocol Specific
   Payload [RFC7178].

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

           Figure 1. RBridge Channel Protocol Message Structure

   An Address Flush RBridge Channel message by default applies to
   addresses within the Data Label in the TRILL Header.  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 the Data
   Label. Such messages SHOULD be sent at priority 6 since they are
   important control messages but lower priority than control messages
   that establish or maintain adjacency.

   Nevertheless:
   -  There are provisions for optionally indicating the Data Label(s)
      to be flushed for cases where the Address Flush message is sent
      over a Managagement VLAN or the like.
   -  An Address Flush message can be sent unicast, if it is desired to
      clear addresses at one TRILL switch only.

W. Hao, et al.                                                  [Page 5]
INTERNET-DRAFT                                     Address Flush Message

2.1 VLAN Block Case

   Figure 2 below expands the RBridge Channel Header and Channel
   Protocol Specific Payload from Figure 1 for the case of the VLAN
   based Address Flush message. This form of the Address Flush message
   is optimized for flushing MAC addressed based on nickname and blocks
   of VLANs.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   RBridge Channel Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    RBridge-Channel (0x8946)   |  0x0  | Channel Protocol = TBD |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Flags        |  ERR  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Address Flush Protocol Specific:
      +-+-+-+-+-+-+-+-+
      | K-nicks       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Nickname 1                    | Nickname 2                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Nickname ...                  | Nickname K-nicks              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | K-VBs         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 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-VBs      | RESV  | End.VLAN K-VBs        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2. Address Flush Message - VLAN Case

   The fields in Figure 2 related to the Address Flush message are as
   follows:

      Channel Protocol:  The RBridge Channel Protocol value allocated
         for Address Flush (see Section 3).

      K-nicks: K-nicks is the number of nicknames present as an unsigned
         integer. If this is zero, the ingress nickname in the TRILL
         Header is considerted to be the only nickname to which the
         message applies. If non-zero, it given the number of nicknames
         present to which the message applies. The messages flushes
         address learning due to egressing TRILL Data packets that had a
         ingress nicknam to which the message applies.

W. Hao, et al.                                                  [Page 6]
INTERNET-DRAFT                                     Address Flush Message

      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 strill operate correctly but will be less
         efficient as the incorrectly flushed learning is re-learned.

      K-VBs: K-VBs is the number of VLAN blocks present as an unsigned
         integer. If this byte is zero, the message is the more general
         format specified in Section 2.2. If it is non-zero, it gives
         the number of blocks of VLANs present.

      RESV: 4 reserved bits. MUST be sent as zero and ignored on
         receipt.

      Start.VLAN, End.VLAN: These 12-bit fields give the beginning and
         ending VLAN IDs of a block of VLANs. The block includes both
         the starting and endiing 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 any other VLAN blocks in
         the message.

   This message flushes all addresses learned from egressing TRILL Data
   packets with an applicable nickname and a VLAN in any of the blocks
   given. 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. This form
   is also extensible to handle future requirements.

   It is indicated by a zero in the byte shown in Figure 2 as "K-VBs".

W. Hao, et al.                                                  [Page 7]
INTERNET-DRAFT                                     Address Flush Message

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   RBridge Channel Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    RBridge-Channel (0x8946)   |  0x0  | Channel Protocol = TBD |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Flags        |  ERR  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Address Flush Protocol Specific:
      +-+-+-+-+-+-+-+-+
      | K-nicks       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Nickname 1                    | Nickname 2                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Nickname ...                  | Nickname K-nicks              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | 0             | Type          | Length                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Type Dependent Information
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...

             Figure 3. Address Flush Message - Extensible Case

      Channel Protocol, K-nicks, Nickname: These fields are as specified
         in Section 2.1.

      Type: If the byte immediately before the Type field, which is the
         byte labeled "K-VBs" in Figure 2, is zero, the the Type byte
         indicates the type of extended Address Flush message as
         follows:

             Type    Description
            ------   ------------
                0     Reserved
                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
         Flush message.

      Type Dependent Information: Depends on the value of the type field
         as further specified below in this section.

W. Hao, et al.                                                  [Page 8]
INTERNET-DRAFT                                     Address Flush Message

   Type 1
   Bit Map of VLANs: The Type Dependent Information consists of two
      bytes with the 12-bit starting VLAN ID N right justified (the top
      4 bits are as specified above for 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 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 3. If Length is 0, 1, or 2 for a
      Type 1 extended Address Flush message, the message is corrupt and
      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
   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
   List of FGLs: The Type Dependent Information 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
      message is considered corrup and MUST be discarded.

   Type 4
   Bit Map of FGLs: The Type Dependent Information consists of three
      bytes with the 24-bit starting FGL 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 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 4. If Length is 0, 1, 2, or 3 for a Type 1 extended Address
      Flush message, the message is corrupt and 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

W. Hao, et al.                                                  [Page 9]
INTERNET-DRAFT                                     Address Flush Message

      FGLs.

   There is no provision for a list of VLAN IDs as there are few enough
   of them that an arbitrary subset of VLAN IDs can always be
   represented as a bit map.

W. Hao, et al.                                                 [Page 10]
INTERNET-DRAFT                                     Address Flush Message

3. IANA Considerations

   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]

4. Security Considerations

   The Address Flush RBridge Channel Protocol provides no security
   assurances or features. However, use of the Address Flush protocol
   can be nested inside the RBridge Channel Tunnel Protocol
   [ChannelTunnel] using the RBridge Channel message payload type. The
   Channel Tunnel protocol can provide security services.

   See [RFC7178] for general RBridge Channel Security Considerations.

   See [RFC6325] for general TRILL Security Considerations.

W. Hao, et al.                                                 [Page 11]
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>.

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.

   [ChannelTunnel] - Eastlake, D., M. Umair, Y. Li, "TRILL: RBridge
         Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work
         in progress.

   [TCaware] - Y. Li, et al., "Aware Spanning Tree Topology Change on
         RBridges" draft-yizhou-trill-tc-awareness, work-in-progress.

Acknowledgements

   The document was prepared in raw nroff. All macros used were defined
   within the source file.

W. Hao, et al.                                                 [Page 12]
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

W. Hao, et al.                                                 [Page 13]
INTERNET-DRAFT                                     Address Flush Message

Copyright, Disclaimer, and Additional IPR Provisions

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.  The definitive version of
   an IETF Document is that published by, or under the auspices of, the
   IETF. Versions of IETF Documents that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of IETF Documents. The
   definitive version of these Legal Provisions is that published by, or
   under the auspices of, the IETF. Versions of these Legal Provisions
   that are published by third parties, including those that are
   translated into other languages, should not be considered to be
   definitive versions of these Legal Provisions.  For the avoidance of
   doubt, each Contributor to the IETF Standards Process licenses each
   Contribution that he or she makes as part of the IETF Standards
   Process to the IETF Trust pursuant to the provisions of RFC 5378. No
   language to the contrary, or terms, conditions or rights that differ
   from or are inconsistent with the rights and licenses granted under
   RFC 5378, shall have any effect and shall be null and void, whether
   published or posted by such Contributor, or included with or in such
   Contribution.

W. Hao, et al.                                                 [Page 14]