Summary

  • RFC 7067, RFC 8171, RFC 8302 and RFC 8380 replace some unknown-unicast and ARP/ND flooding with directory answers. The saving depends on preserving the difference between complete and incomplete knowledge, positive and negative replies, and fresh and cached state.
  • A directory transports a reachability claim; it does not create the truth of that claim. Origin, confidence, lifetime, update handling, mobility observation and channel security remain separate duties, and stronger reliance raises the cost of a false answer.

Analysis

The answer that survived the machine

The difficult failure is not a directory that refuses to answer. It is one that answers confidently after the world has moved on. A virtual machine changes racks. Its IP and MAC addresses remain familiar, but the egress RBridge through which it can be reached changes. A client that cached the earlier mapping still possesses valid syntax and obsolete reachability.

Flooding deals with ignorance by asking the surrounding network. A directory offers a more economical bargain: ask once, or receive the mapping in advance, and send directly. The reduction in repeated unknown-unicast, ARP and IPv6 Neighbor Discovery traffic can matter as a data centre grows. Yet the optimisation converts a distributed question into reliance on a record. The record now needs an origin, a scope, a statement of completeness, an expiry and a path for correction.

Linda Dunbar appears in a four-document sequence that makes this bargain unusually visible. She co-authored RFC 7067 with Donald Eastlake, Radia Perlman and Igor Gashinsky; RFC 8171 with Donald Eastlake 3rd, Radia Perlman and Yizhou Li; RFC 8302 with Yizhou Li, Donald Eastlake 3rd, Radia Perlman and Muhammad Umair; and RFC 8380 with Donald Eastlake 3rd and Radia Perlman. This is collective IETF work, not a personal invention. Her Datatracker record supports attribution of participation, not ownership of the protocols or their outcomes.

The sequence also has different authority levels. RFC 7067, published in November 2013, is Informational and expressly not an Internet Standards Track specification. RFC 8171, RFC 8302 and RFC 8380 are Standards Track documents published from June 2017 to May 2018. Keeping those statuses separate matters because a problem framework, a protocol mechanism and a deployed result are not interchangeable evidence.

Push, Pull and the meaning of absence

RFC 7067 frames two models. A Push Directory distributes address-to-location information to interested TRILL switches in advance. A Pull Directory answers when a switch encounters an address it does not know. The client may cache a Pull response, exchanging later floods and queries for trust in the retained answer.

The important distinction is not simply Push versus Pull. It is complete versus incomplete knowledge. A directory with incomplete coverage can truthfully say that it has no record for an address, but that means “unknown here”, not “the endpoint does not exist”. A directory that genuinely covers every relevant endpoint in a Data Label can make the stronger negative claim.

RFC 8171 gives this distinction operational force: when complete mapping information has been pushed, an ingress RBridge may drop traffic for an absent unicast destination rather than flood it. If the completeness assertion is wrong, the same optimisation discards reachable traffic.

Completeness is therefore not decorative metadata. It changes the receiver's permitted action. A positive answer can direct a frame. A negative answer from a complete source can suppress discovery. A negative answer from an incomplete source must preserve uncertainty. Systems that flatten these states into one “not found” value erase the very boundary that makes directory assistance safe.

RFC 8171 also separates the transport of a record from the production of truth. A primary server is defined as obtaining its information through a reliable mechanism designed to assure freshness, but the mechanism is outside the RFC's scope. A secondary server may receive data from primary servers. The protocol can identify who supplied the answer and move it consistently; it cannot prove that an orchestration database noticed a migration or that an operator entered the right attachment point.

A cache is a promise with a deadline

Pull answers save work because clients retain them. That economy creates a second state system: the server has current data, while one or more clients may still hold earlier positive or negative replies. RFC 8171 requires a Pull server that uses non-zero lifetimes to take action, through Update messages, to minimise the time clients continue using stale information.

The document defines three levels of record keeping. At the least specific level, the server remembers aggregate expiry by Data Label and may have to flush broad groups of cached answers when something changes. At the most specific level, it tracks which clients may hold which positive or negative result and until when, allowing targeted correction at greater storage and coordination cost. The middle method trades between those burdens.

This is not mere implementation housekeeping. Suppose a previously absent endpoint is created after a client cached a negative answer. Unless that negative state is invalidated, the new machine remains unreachable to that client even though the directory now knows it exists. Suppose a machine moves after a positive answer was cached. Until the answer expires or an update arrives, traffic follows the old attachment point. RFC 8171 acknowledges that brief stale windows can remain even when the mechanisms are followed.

A lifetime is thus a bounded permission to rely, not a certificate of continuing truth. Longer lifetimes reduce queries and update pressure but enlarge the interval during which mobility can invalidate an answer. Shorter lifetimes demand more control traffic and server work but make correction faster. The right value depends on the environment; it cannot be inferred from protocol compliance alone.

Confidence is not authority

RFC 8302 brings directory state into ARP/ND optimisation. An RBridge can build IP/MAC/Data Label bindings from management, a directory or other control-plane mechanism, and data-plane observation. These sources do not necessarily agree. The RFC's confidence-level feature lets an implementation express their configured relative reliability and arbitrate conflicts.

That feature is deliberately local. The specification does not declare that directory information always defeats observed packets or that the latest arrival is always right. An operator may regard complete, protected orchestration data as stronger than forgeable ARP. In another environment, directory coverage may be incomplete and live data-plane learning may supply a necessary correction. The implementation decides how confidence is assigned.

Complete and trustworthy directory information can bound the damage from forged ARP or ND messages. But “complete” and “trustworthy” are conditions that must be established; they are not benefits created by writing the word directory. Data-plane learning without SEND is itself forgeable. Directory mode shifts the trust surface to population, distribution and administration. A confidence number makes the choice visible. It does not remove the need to justify it.

Mobility supplies the practical test. RFC 8302 says a locally learned dynamic entry must be removed when its link fails and should age out when not refreshed. When an end station moves from one edge RBridge to another, the new location should replace the old one and remote caches should update. The directory's value is measured by how well its record follows that observed transition, not by how centrally the record is held.

Earlier knowledge increases the blast radius

RFC 8380 lets certain non-RBridge nodes use directory assistance to pre-encapsulate TRILL traffic toward the remote egress RBridge. The recipient can avoid sending an ordinary native frame to an ingress RBridge that would otherwise have to discover or flood the destination. More knowledge moves closer to the source, and some work leaves the network edge.

The security section is candid about the trade. An untrusted assisted node can forge ingress or egress nicknames and inner or outer MAC addresses. It may learn substantial information about the TRILL topology. If an attacker compromises the directory path, false mappings can send packets to the wrong destination and violate policy about which end station should receive them. Authentication and encryption are recommended between the directory and the assisted node, together with proper patching, configuration and minimal access.

Protection of the channel is necessary but not sufficient. Encryption can show that a false mapping came through the expected session; it cannot turn the mapping into a correct description of a moved endpoint. Authentication answers who spoke. Completeness answers what coverage was claimed. Confidence answers how the receiver ranks the claim. Lifetime bounds how long it may be retained. Live forwarding evidence answers whether the network still agrees. These are related controls, not substitutes.

The directory as a bounded service

Lu Heng's later argument for Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption offers Sofia Ren a useful reading of this design. Share only the fields required to coordinate an address and a reachable location. Leave confidence policy, cache strategy, fallback and risk acceptance close to the systems that bear the result. This is an editorial comparison, not a claim about the RFC authors' private intentions.

The same limit appears in Running-Code Primacy. A directory record is valuable because forwarding systems can use it. That use also makes observed operation the final test. If packets, mobility events or edge state contradict the record, the record must be corrected, expired or bypassed. A bookkeeper of reachability cannot earn authority to overrule reachability.

Linda Dunbar's co-authored record does not prove that any particular deployment met this standard. The RFCs provide no measurements of flooding reduction, cache accuracy, adoption or incident prevention. What they do provide is a disciplined vocabulary for asking the right questions. Is the source complete? Who supplied it? Which clients still hold it? How confident is the receiver? What changed after a move? Can a protected but wrong answer be displaced?

The directory may answer for the network. It must remain possible for the network to answer back.

Sources