tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8171

Proposed STD
Pages: 55
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: TRILL

Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms

Part 1 of 3, p. 1 to 17
None       Next Section

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 8171                                     L. Dunbar
Category: Standards Track                                         Huawei
ISSN: 2070-1721                                               R. Perlman
                                                                     EMC
                                                                   Y. Li
                                                                  Huawei
                                                               June 2017


         Transparent Interconnection of Lots of Links (TRILL):
                  Edge Directory Assistance Mechanisms

Abstract

   This document describes mechanisms for providing directory service to
   TRILL (Transparent Interconnection of Lots of Links) edge switches.
   The directory information provided can be used in reducing multi-
   destination traffic, particularly ARP / Neighbor Discovery (ND) and
   unknown unicast flooding.  It can also be used to detect traffic with
   forged source addresses.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc8171.

Top      ToC       Page 2 
Copyright Notice

   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.

Table of Contents

   1. Introduction ....................................................3
      1.1. Uses of Directory Information ..............................5
      1.2. Terminology ................................................6
   2. Push Model Directory Assistance Mechanisms ......................7
      2.1. Requesting Push Service ....................................7
      2.2. Push Directory Servers .....................................8
      2.3. Push Directory Server State Machine ........................9
           2.3.1. Push Directory States ...............................9
           2.3.2. Push Directory Events and Conditions ...............11
           2.3.3. State Transition Diagram and Table .................13
      2.4. End Stations and Push Directories .........................15
      2.5. Additional Push Details ...................................15
      2.6. Providing Secondary Servers with Data from a
           Primary Server ............................................16
      2.7. Push Directory Configuration ..............................17
   3. Pull Model Directory Assistance Mechanisms .....................17
      3.1. Pull Directory Message: Common Format .....................19
           3.1.1. Version Negotiation ................................20
      3.2. Pull Directory Query and Response Messages ................21
           3.2.1. Pull Directory Query Message Format ................21
           3.2.2. Pull Directory Responses ...........................24
                  3.2.2.1. Pull Directory Response Message Format ....24
                  3.2.2.2. Pull Directory Forwarding .................27
      3.3. Cache Consistency .........................................28
           3.3.1. Update Message Format ..............................32
           3.3.2. Acknowledge Message Format .........................33
      3.4. Summary of Record Formats in Messages .....................34

Top      ToC       Page 3 
      3.5. End Stations and Pull Directories .........................34
           3.5.1. Pull Directory Hosted on an End Station ............35
           3.5.2. Use of Pull Directory by End Stations ..............36
           3.5.3. Native Pull Directory Messages .....................37
      3.6. Pull Directory Message Errors .............................38
           3.6.1. Error Codes ........................................39
           3.6.2. Sub-errors under Error Codes 1 and 3 ...............39
           3.6.3. Sub-errors under Error Codes 128 and 131 ...........40
      3.7. Additional Pull Details ...................................40
      3.8. The "No Data" Flag ........................................40
      3.9. Pull Directory Service Configuration ......................42
   4. Directory Use Strategies and Push-Pull Hybrids .................42
   5. TRILL ES-IS ....................................................44
      5.1. PDUs and System IDs .......................................45
      5.2. Adjacency, DRB Election, Port IDs, Hellos, and TLVs .......46
      5.3. Link State ................................................47
   6. Security Considerations ........................................47
      6.1. Directory Information Security ............................47
      6.2. Directory Confidentiality and Privacy .....................47
      6.3. Directory Message Security Considerations .................48
   7. IANA Considerations ............................................48
      7.1. ESADI-Parameter Data Extensions ...........................48
      7.2. RBridge Channel Protocol Numbers ..........................49
      7.3. The Pull Directory (PUL) and No Data (NOD) Bits ...........49
      7.4. TRILL Pull Directory QTYPEs ...............................50
      7.5. Pull Directory Error Code Registries ......................50
      7.6. TRILL-ES-IS MAC Address ...................................51
   8. References .....................................................51
      8.1. Normative References ......................................51
      8.2. Informative References ....................................54
   Acknowledgments ...................................................55
   Authors' Addresses ................................................55

Top      ToC       Page 4 
1.  Introduction

   [RFC7067] gives a problem statement and high-level design for using
   directory servers to assist TRILL [RFC6325] [RFC7780] edge nodes in
   reducing multi-destination ARP / Neighbor Discovery (ND) [ARPND],
   reducing unknown unicast flooding traffic, and improving security
   against address spoofing within a TRILL campus.  Because
   multi-destination traffic becomes an increasing burden as a network
   scales up in number of nodes, reducing ARP/ND and unknown unicast
   flooding improves TRILL network scalability.  This document describes
   specific mechanisms for TRILL directory servers.

   The information held by the directory or directories is address
   mapping and reachability information -- most commonly, what MAC
   (Media Access Control) address [RFC7042] corresponds to an IP address
   within a Data Label (VLAN or FGL (Fine-Grained Label) [RFC7172]) and
   the egress TRILL switch (RBridge), and, optionally, what specific
   port on that TRILL switch, from which that MAC address is reachable.
   But it could be what IP address corresponds to a MAC address or
   possibly other address mapping or reachability information.

   The mechanism used to initially populate directory data in primary
   servers is beyond the scope of this document.  A primary server can
   use the Push Directory service to provide directory data to secondary
   servers, as described in Section 2.6.  In the data-center
   environment, it is common for orchestration software to know and
   control where all the IP addresses, MAC addresses, and VLANs/tenants
   are in a data center.  Thus, such orchestration software can be
   appropriate for providing the directory function or for supplying the
   directory or directories with directory information.

   Efficient routing of unicast traffic in a TRILL campus assumes that
   the mapping of destination MAC addresses to edge RBridges is stable
   enough that the default data-plane learning of TRILL and/or the use
   of directories reduces to an acceptable level the need to flood
   packets where the location of the destination is unknown.  Although
   not prohibited, "ephemeral" MAC addresses are unlikely to be used in
   such an environment.  Directories need not be complete, and in the
   case that any ephemeral MAC addresses were in use, they would
   probably not be included in directory information.

   Directory services can be offered in a Push Mode, Pull Mode, or both
   [RFC7067] at the discretion of the server.  Push Mode, in which a
   directory server pushes information to TRILL switches indicating
   interest, is specified in Section 2.  Pull Mode, in which a TRILL
   switch queries a server for the information it wants, is specified in
   Section 3.  More detail on modes of operation, including hybrid
   Push/Pull, are provided in Section 4.

Top      ToC       Page 5 
1.1.  Uses of Directory Information

   A TRILL switch can consult directory information whenever it wants by
   (1) searching through information that has been retained after being
   pushed to it or pulled by it or (2) requesting information from a
   Pull Directory.  However, the following are expected to be the most
   common circumstances leading to the use of directory information.
   All of these are cases of ingressing (or originating) a native frame.

   1. ARP requests and replies [RFC826] are normally broadcast.  But a
      directory-assisted edge TRILL switch could intercept ARP messages
      and reply if the TRILL switch has the relevant information
      [ARPND].

   2. IPv6 ND [RFC4861] requests and replies are normally multicast.
      Except in the case of Secure Neighbor Discovery (SEND) [RFC3971],
      where possession of the right keying material might be required, a
      directory-assisted edge TRILL switch could intercept ND messages
      and reply if the TRILL switch has the relevant information
      [ARPND].

   3. Unknown destination MAC addresses normally cause a native frame to
      be flooded.  An edge TRILL switch ingressing a native frame
      necessarily has to determine if it knows the egress RBridge from
      which the destination MAC address of the frame (in the frame's
      VLAN or FGL) is reachable.  It might have learned that information
      from the directory or could query the directory if it does not
      know it.  Furthermore, if the edge TRILL switch has complete
      directory information, it can detect a forged source MAC or IP
      address in any native frame and discard the frame if it finds such
      a forged address.

   4. RARP [RFC903] (Reverse ARP) is similar to ARP (item 1 above).

Top      ToC       Page 6 
1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   The terminology and abbreviations of [RFC6325] are used herein, along
   with the following:

   AFN: Address Family Number
      (http://www.iana.org/assignments/address-family-numbers/).

   CSNP Time: Complete Sequence Number Protocol Data Unit (PDU) time.
      See ESADI [RFC7357] and Section 7.1 below.

   Data Label: VLAN or FGL.

   ESADI: End Station Address Distribution Information [RFC7357].

   FGL: Fine-Grained Label [RFC7172].

   FR: Flood Record flag bit.  See Section 3.2.1.

   Host: A physical server or a virtual machine.  A host must have a MAC
      address and usually has at least one IP address.

   Interested Labels sub-TLV: Short for "Interested Labels and Spanning
      Tree Roots sub-TLV" [RFC7176].

   Interested VLANs sub-TLV: Short for "Interested VLANs and Spanning
      Tree Roots sub-TLV" [RFC7176].

   IP: Internet Protocol.  In this document, IP includes both IPv4
      and IPv6.

   MAC address: Media Access Control address [RFC7042].

   MacDA: Destination MAC address.

   MacSA: Source MAC address.

   OV: Overflow flag bit.  See Section 3.2.2.1.

   PDSS: Push Directory Server Status.  See Sections 2 and 7.1.

Top      ToC       Page 7 
   Primary server: A directory server that obtains the information it is
      providing by a reliable mechanism designed to assure the freshness
      of that information.  This mechanism is outside the scope of this
      document.  (See "Secondary server" below.)

   PUL: Pull Directory flag bit.  See Sections 3 and 7.3.

   RBridge: An alternative name for a TRILL switch.

   Secondary server: A directory server that obtains the information it
      is providing from one or more primary servers.

   TLV: Type, Length, Value.

   TRILL: Transparent Interconnection of Lots of Links or Tunneled
      Routing in the Link Layer.

   TRILL switch: A device that implements the TRILL protocol.

2.  Push Model Directory Assistance Mechanisms

   In the Push Model [RFC7067], one or more Push Directory servers
   reside at TRILL switches and "push down" the address mapping
   information for the various addresses associated with end-station
   interfaces and the TRILL switches from which those interfaces are
   reachable [RFC7961].  This service is scoped by Data Label (VLAN or
   FGL [RFC7172]).  A Push Directory advertises when, for a Data Label,
   it is configured to be a directory having complete information and
   also has actually pushed all the information it has.  It might be
   pushing only a subset of the mapping and/or reachability information
   for a Data Label.  The Push Model uses the ESADI [RFC7357] protocol
   as its distribution mechanism.

   With the Push Model, if complete address mapping information for a
   Data Label is being pushed, a TRILL switch (RBridge) that has that
   complete information and is ingressing a native frame can simply drop
   the frame if the destination unicast MAC address can't be found in
   the mapping information available, instead of flooding the frame
   (ingressing it as an unknown MAC destination TRILL Data frame).  But
   this will result in lost traffic if the ingress TRILL switch's
   directory information is incomplete.

2.1.  Requesting Push Service

   In the Push Model, it is necessary to have a way for a TRILL switch
   to subscribe to information from the directory server(s).  TRILL
   switches simply use the ESADI [RFC7357] protocol mechanism to
   announce, in their core IS-IS Link State PDUs (LSPs), the Data Labels

Top      ToC       Page 8 
   for which they are participating in ESADI by using the Interested
   VLANs sub-TLV [RFC7176] and/or the Interested Labels sub-TLV
   [RFC7176].  This will cause the directory information to be pushed to
   them for all such Data Labels that are being served by the one or
   more Push Directory servers.

2.2.  Push Directory Servers

   Push Directory servers advertise, through ESADI, their availability
   to push the mapping information for a particular Data Label by
   setting the PDSS in their ESADI-Parameter APPsub-TLV for that ESADI
   instance (see [RFC7357] and Section 7.1) to a non-zero value.  This
   PDSS field setting is visible to other ESADI participants, including
   other Push Directory servers, for that Data Label.  Each Push
   Directory server MUST participate in ESADI for the Data Labels for
   which it will push mappings and set the PDSS field in its
   ESADI-Parameter APPsub-TLV for that Data Label.  For increased
   robustness, increased bandwidth capability, and improved locality, it
   is useful to have multiple Push Directory servers for each
   Data Label.  Each Push Directory server is configured with a
   number N, which is in the range 1 through 8 and defaults to 2, for
   each Data Label for which it can push directory information (see
   "PushDirServers" in Section 2.7).  If the Push Directory servers for
   a Data Label are configured consistently with the same N and at least
   N servers are available, then N copies of that directory will be
   pushed.

   Each Push Directory server also has a configurable 8-bit priority
   (PushDirPriority) to be Active, which defaults to 0x3F (see
   Section 2.7).  This priority is treated as an unsigned integer, where
   the larger magnitude means higher priority.  This priority appears in
   its ESADI-Parameter APPsub-TLV (see Section 7.1).  In the case of a
   tie in this configurable priority, the System ID of the TRILL switch
   acting as the server is used as a tiebreaker and is treated as an
   unsigned 6-byte integer, where the larger magnitude indicates higher
   priority.

   For each Data Label it can serve, each Push Directory server checks
   to see if there appear to be enough higher-priority servers to push
   the desired number of copies.  It does this by ordering, by priority,
   the Push Directory servers whose advertisements are present in the
   ESADI link-state database for that Data Label and that are
   data reachable [RFC7780] as indicated by its IS-IS link-state
   database.  The Push Directory server then determines its own position
   in that order.  If a Push Directory server's configuration indicates
   that N copies of the mappings for a Data Label should be pushed and
   the server finds that it is number K in the priority ordering (where
   number 1 in the ordered list is highest priority and the last is

Top      ToC       Page 9 
   lowest priority), then if K is less than or equal to N, the Push
   Directory server is Active.  If K is greater than N, it is Stand-By.
   Active and Stand-By behavior are specified below in Section 2.3.

   For a Push Directory to reside on an end station, one or more TRILL
   switches locally connected to that end station must proxy for the
   Push Directory server and advertise themselves in ESADI as Push
   Directory servers.  It appears to the rest of the TRILL campus that
   these TRILL switches (that are proxying for the end station) are the
   Push Directory server(s).  The protocol between such a Push Directory
   end station and the one or more proxying TRILL switches acting as
   Push Directory servers is beyond the scope of this document.

2.3.  Push Directory Server State Machine

   The subsections below describe the states, events, and corresponding
   actions for Push Directory servers.

   The meanings of possible values of the PDSS field in a Push
   Directory's ESADI-Parameter APPsub-TLV are summarized in the table
   below.

       PDSS         Meaning
       ----   ------------------------------------------------------
         0     Not a Push Directory server
         1     Push Directory server in Stand-By Mode
         2     Push Directory server in Active Mode but not complete
         3     Push Directory server in Active Mode that has pushed
               complete data

2.3.1.  Push Directory States

   A Push Directory server is in one of seven states, as listed below,
   for each Data Label it can serve.  The name of each state is followed
   by a symbol that starts and ends with an angle bracket (for example,
   "<S1>") and represents the state.  The value that the Push Directory
   server advertises in the PDSS is determined by the state.  In
   addition, it has an internal State-Transition-Time variable for each
   Data Label it serves that is set at each state transition and that
   enables it to determine how long it has been in its current state for
   that Data Label.

Top      ToC       Page 10 
   Down <S1>: A completely shut down virtual state, defined for
      convenience in specifying state diagrams.  A Push Directory server
      in this state does not advertise any Push Directory data.  It may
      be participating in ESADI [RFC7357] with the PDSS field set to 0
      in its ESADI-Parameter APPsub-TLV, or it might not be
      participating in ESADI at all.  All states other than the Down
      state are considered to be Up states and imply a non-zero
      PDSS field.

   Stand-By <S2>: No Push Directory data is advertised.  Any outstanding
      ESADI-LSP fragments containing directory data are updated to
      remove that data, and if the result is an empty fragment (contains
      nothing except possibly an Authentication TLV), the fragment is
      purged.  The Push Directory participates in ESADI [RFC7357] and
      advertises its ESADI fragment zero that includes an
      ESADI-Parameter APPsub-TLV with the PDSS field set to 1.

   Active <S3>: The Push Directory participates in ESADI [RFC7357] and
      advertises its ESADI fragment zero that includes an
      ESADI-Parameter APPsub-TLV with the PDSS field set to 2.  It also
      advertises its directory data and any changes through ESADI
      [RFC7357] in its ESADI-LSPs, using the Interface Addresses
      APPsub-TLV [RFC7961], and updates that information as it changes.

   Active Completing <S4>: The same behavior as the Active state, except
      that the server responds differently to events.  The purpose of
      this state is to be sure that there has been enough time for
      directory information to propagate to subscribing edge TRILL
      switches (see "Time Condition", as defined in Section 2.3.2)
      before the directory server advertises that the information is
      complete.

   Active Complete <S5>: The same behavior as Active, except that the
      PDSS field in the ESADI-Parameter APPsub-TLV is set to 3 and the
      server responds differently to events.

   Going Stand-By Was Complete <S6>: The same behavior as Active, except
      that the server responds differently to events.  The purpose of
      this state is to be sure that the information indicating that the
      directory will no longer be complete has enough time to propagate
      to edge TRILL switches (see "Time Condition" in Section 2.3.2)
      before the directory server stops advertising updates to the
      information.  (See note below.)

   Active Uncompleting <S7>: The same behavior as Active, except that it
      responds differently to events.  The purpose of this state is to
      be sure that the information indicating that the directory will no
      longer be complete has enough time to propagate to edge TRILL

Top      ToC       Page 11 
      switches (see "Time Condition" in Section 2.3.2) before the
      directory server might stop advertising updates to the
      information.  (See note below.)

      Note: It might appear that a Push Directory could transition
      directly from Active Complete to Active, since the Active state
      continues to advertise updates, eliminating the need for the
      Active Uncompleting transition state.  But consider the case of
      the Push Directory that was complete being configured to be
      incomplete and then the Stand-By Condition (see Section 2.3.2)
      occurring shortly thereafter.  If the first of these two events
      caused the server to transition directly to the Active state,
      then later, when the Stand-By Condition occurred, it would
      immediately transition to Stand-By and stop advertising updates
      even though there might not have been enough time for knowledge of
      its incompleteness to have propagated to all edge TRILL switches.

   The following table lists each state and its corresponding PDSS
   value:

       State                                 PDSS
      --------------------------------      ------
      Down <S1>                               0
      Stand-By <S2>                           1
      Active <S3>                             2
      Active Completing <S4>                  2
      Active Complete <S5>                    3
      Going Stand-By Was Complete <S6>        2
      Active Uncompleting <S7>                2

2.3.2.  Push Directory Events and Conditions

   Three auxiliary conditions, referenced later in this subsection, are
   defined as follows:

   The Activate Condition: In order to have the desired number of Push
      Directory servers pushing data for Data Label X, this Push
      Directory server should be active.  This is determined by the
      server finding that (a) it is priority K among the data-reachable
      Push Directory servers (where the highest-priority server is 1)
      for Data Label X, (b) it is configured that there should be
      N copies pushed for Data Label X, and (c) K is less than or equal
      to N.  For example, the Push Directory server is configured so
      that two copies should be pushed and finds that it is priority 1
      or 2 among the Push Directory servers that are visible in its
      ESADI link-state database and that are data reachable, as
      indicated by its IS-IS link-state database.

Top      ToC       Page 12 
   The Stand-By Condition: In order to have the desired number of Push
      Directory servers pushing data for Data Label X, this Push
      Directory server should be Stand-By (not Active).  This is
      determined by the server finding that (a) it is priority K among
      the data-reachable Push Directory servers (where the
      highest-priority server is 1) for Data Label X, (b) it is
      configured that there should be N copies pushed for Data Label X,
      and (c) K is greater than N.  For example, the Push Directory
      server is configured so that two copies should be pushed and finds
      that it is priority 3 or lower priority (higher number) among the
      available Push Directory servers.

   The Time Condition: The Push Directory server has been in its current
      state for a configurable amount of time (PushDirTimer) that
      defaults to twice its CSNP (Complete Sequence Number PDU) time
      (see Sections 2.7 and 7.1).

   The events and conditions listed below cause state transitions in
   Push Directory servers.

   1. The Push Directory server comes up.

   2. The Push Directory server or the TRILL switch on which it resides
      is being shut down.  This is a persistent condition, unless the
      shutdown is canceled.  So, for example, a Push Directory server in
      the Going Stand-By Was Complete state does not transition out of
      that state due to this condition but, after (1) the Time Condition
      is met and (2) the directory transitions to Stand-By and then
      performs the actions required there (such as purging LSPs),
      continues to the Down state if this condition is still true.
      Similar comments apply to events/conditions 3, 4, and 5.

   3. The Activate Condition is met, and the server's configuration
      indicates that it does not have complete data.

   4. The Stand-By Condition is met.

   5. The Activate Condition is met, and the server's configuration
      indicates that it has complete data.

   6. The server's configuration is changed to indicate that it does not
      have complete data.

   7. The Time Condition is met.

Top      ToC       Page 13 
2.3.3.  State Transition Diagram and Table

   The state transition table is as follows:

     |    |        |      |  Active  | Active |   Going    |   Active
State|Down|Stand-By|Active|Completing|Complete|  Stand-By  |Uncompleting
-----+    |        |      |          |        |Was Complete|
Event|<S1>|  <S2>  | <S3> |   <S4>   |  <S5>  |    <S6>    |    <S7>
-----+----+--------+------+----------+--------+------------+------------
  1  |<S2>|  N/A   | N/A  |   N/A    |  N/A   |  N/A       |    N/A
  2  |<S1>|  <S1>  | <S2> |   <S2>   |  <S6>  |  <S6>      |    <S7>
  3  |<S1>|  <S3>  | <S3> |   <S3>   |  <S7>  |  <S3>      |    <S7>
  4  |<S1>|  <S2>  | <S2> |   <S2>   |  <S6>  |  <S6>      |    <S6>
  5  |<S1>|  <S4>  | <S4> |   <S4>   |  <S5>  |  <S5>      |    <S5>
  6  |<S1>|  <S2>  | <S3> |   <S3>   |  <S7>  |  <S6>      |    <S7>
  7  |<S1>|  <S2>  | <S3> |   <S5>   |  <S5>  |  <S2>      |    <S3>

Top      ToC       Page 14 
   The above state table is equivalent to the following transition
   diagram:

      +-----------+
      | Down <S1> |<---------+
      +-----------+          |
        |1  ^   | 3,4,5,6,7  |
        |   |   +------------+
        V   |2
      +---------------+
      | Stand-By <S2> |<--------------------------------------+
      +---------------+    ^   ^            ^                 |
        |5   |3  |1,4,6,7  |   |            |                 |
        |    |   +---------+   |            |                 |
        |    V                 |2,4         |                 |
        |  +---------------------+          |                 |
        |  | Active <S3>         |<---------|-------------+   |
        |  +---------------------+     ^    |             |   |
        |   |5  ^    |1,3,6,7  ^       |    |             |   |
        |   |   |    |         |       |    |             |   |
        |   |   |    +---------+       |    |             |   |
        |   |   |                      |    |             |   |
        V   V   |3,6                   |    |             |   |
      +------------------------+       |    |             |   |
      | Active Completing <S4> |------------+             |   |
      +------------------------+ 2,4   |                  |   |
        |7  |1,5    ^                  |                  |   |
        |   |       |                  |                  |   |
        |   +-------+                  |                  |   |
        |                              |                  |   |
        |        +------------------------------------+   |   |
        |        |                     |              |   |   |
        V        V                     |7             |5  |3  |7
      +-------------+ 3,6    +----------------+ 4  +----------------+
      |    Active   |------->|     Active     |--->| Going Stand-By |
      |   Complete  |        |  Uncompleting  |    |  Was Complete  |
      |     <S5>    |<-------|      <S7>      |    |      <S6>      |
      +-------------+      5 +----------------+    +----------------+
       |1,5,7  ^  |2,4         |1,2,3,6     ^        ^   |1,2,4,6 ^
       |       |  |            |            |        |   |        |
       +-------+  |            +------------+        |   +--------+
                  |                                  |
                  +----------------------------------+

                    Figure 1: Push Server State Diagram

Top      ToC       Page 15 
2.4.  End Stations and Push Directories

   End-station hosting and end-station use of Push Directories are
   outside the scope of this document.  Push Directory information
   distribution is accomplished using ESADI [RFC7357], which does not
   operate to end stations.  In the future, ESADI might be extended to
   operate to end stations, or some other method, such as BGP, might be
   specified as a way to support end-station hosting or end-station use
   of Push Directories.

2.5.  Additional Push Details

   Push Directory mappings can be distinguished from other data
   distributed through ESADI, because mappings are distributed only with
   the Interface Addresses APPsub-TLV [RFC7961] and are flagged in that
   APPsub-TLV as being Push Directory data.

   TRILL switches, whether or not they are Push Directory servers, MAY
   continue to advertise any locally learned MAC attachment information
   in ESADI [RFC7357] using the MAC-Reachability TLV [RFC6165].
   However, if a Data Label is being served by complete Push Directory
   servers, advertising such a locally learned MAC attachment generally
   SHOULD NOT be done, as it would not add anything and would just waste
   bandwidth and ESADI link-state space.  An exception might be when a
   TRILL switch learns local MAC connectivity and that information
   appears to be missing from the directory mapping.

   Because a Push Directory server needs to advertise interest in one or
   more Data Labels even though it might not want to receive
   multi-destination TRILL Data packets in those Data Labels, the
   "No Data" (NOD) flag bit is provided, as discussed in Section 3.8.

   When a Push Directory server is no longer data reachable [RFC7780],
   as indicated by the IS-IS link-state database, other TRILL switches
   MUST ignore any Push Directory data from that server, because it is
   no longer being updated and may be stale.

   The nature of dynamic distributed asynchronous systems is such that
   it is impossible for a TRILL switch receiving Push Directory
   information to be absolutely certain that it has complete
   information.  However, it can obtain a reasonable assurance of
   complete information by requiring that two conditions be met:

   1. The PDSS field is 3 in the ESADI fragment zero from the server for
      the relevant Data Label.

Top      ToC       Page 16 
   2. As far as it can tell, it has had continuous data connectivity to
      the server for a configurable amount of time that defaults to
      twice the server's CSNP time (see "PushDirTimer" in Section 2.7).

   Condition 2 is necessary because a client TRILL switch might be just
   coming up and receive an ESADI-LSP meeting the requirement in
   condition 1 above but has not yet received all of the ESADI-LSP
   fragments from the Push Directory server.

   Likewise, due to various delays, when an end station connects to or
   disconnects from the campus, there are timing differences between
   such a connection or disconnection, the update of directory
   information at the directory, and the update of directory information
   at any particular RBridge in the TRILL campus.  Thus, there is
   commonly a small window during which an RBridge using directory
   information might either (1) drop or unnecessarily flood a frame as
   having an unknown unicast destination or (2) encapsulate a frame to
   an edge RBridge where the end station is no longer connected when the
   frame arrives at that edge RBridge.

   There may be conflicts between mapping information from different
   Push Directory servers or conflicts between locally learned
   information and information received from a Push Directory server.
   In cases of such conflicts, information with a higher confidence
   value [RFC6325] [RFC7961] is preferred over information with a lower
   confidence value.  In cases of equal confidence values, Push
   Directory information is preferred to locally learned information,
   and if information from Push Directory servers conflicts, the
   information from the higher-priority Push Directory server is
   preferred.

2.6.  Providing Secondary Servers with Data from a Primary Server

   A secondary Push or Pull Directory server is one that obtains its
   data from a primary directory server.  Such systems, where some
   directory servers can be populated from others, have been found
   useful for multiple-server directory applications -- for example, in
   the DNS, where it is the normal case that some authoritative servers
   (secondary servers) are populated with data from other authoritative
   servers (primary servers).

   Other techniques MAY be used, but by default, this data transfer
   occurs through the primary server acting as a Push Directory server
   for the Data Labels involved, while the secondary directory server
   takes the pushed data it receives from the highest-priority Push
   Directory server and re-originates it.  Such a secondary server
   may be a Push Directory server, a Pull Directory server, or both for
   any particular Data Label.  Because the data from a secondary server

Top      ToC       Page 17 
   will necessarily be at least a little less fresh than that from a
   primary server, it is RECOMMENDED that the re-originated secondary
   server's data be given a confidence level at least one less than that
   of the data as received from the primary server (or unchanged if it
   is already of minimum confidence).

2.7.  Push Directory Configuration

   The following configuration parameters, per Data Label, are available
   for controlling Push Directory behavior:

            Name          Range/Setting     Default       Section
      ---------------     -------------    ---------    ------------
      PushDirService         true/false        false    2.2
      PushDirServers                1-8            2    2.2
      PushDirPriority             0-255         0x3F    2.2
      PushDirComplete        true/false        false    2.3.1, 2.3.2
      PushDirTimer                1-511     2 * CSNP    2.3.2, 2.5

   PushDirService is a boolean.  When false, Push Directory service is
   not provided; when true, it is.

   PushDirComplete is a boolean.  When false, the server never indicates
   that the information it has pushed is complete; when true, it does so
   indicate after pushing all the information it knows.

   PushDirTimer defaults to two times the ESADI-CSNP configuration value
   but not less than 1 second.



(page 17 continued on part 2)

Next Section