Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8171

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

Pages: 55
Proposed Standard
Part 1 of 3 – Pages 1 to 17
None   None   Next

Top   ToC   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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   RFC8171 - 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