RFC 8171
Transparent Interconnection of Lots of Links (TRILL): Edge Directory Assistance Mechanisms
Pages: 55
Proposed Standard
Proposed Standard
Part 1 of 3 – Pages 1 to 17
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 MechanismsAbstract
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.
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
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
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.
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).
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.
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
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
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 data2.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.
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
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.
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.
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>
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
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.
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
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)