Jeffrey Haas and the Failure-State Discipline Behind BGP and BFD

Summary

Jeffrey Haas’s person-attributed standards record traces a practical sequence of failure-state boundaries: RFC 4273 exposes BGP peer state and errors; RFC 7130 detects failure at individual LAG members; RFC 8538 distinguishes graceful handling from a hard reset; RFC 9384 attributes a BGP termination to BFD; and RFC 9774 removes unordered AS path segments that obscure routing state.
The sequence improves the vocabulary available to implementers and operators, not the certainty of outcomes. Signals can be missing, stale, misconfigured, or only partially delivered; requirements do not prove adoption; and authority remains distributed among IETF consensus, co-authors, implementations, vendors, operational policy, and the network’s observed behavior.

Failure state needs a boundary

A routing failure is not one thing. It may begin as a physical member link that no longer forwards in both directions, appear as a BFD session entering Down, cause a BGP connection to close, leave a peer holding stale routes, or expose path information whose meaning is too ambiguous for a safe decision. Each stage has a different observer and a different possible action. A useful standard does not erase those distinctions. It gives each transition a name, limits what that name means, and identifies what another component may do with it.

That is the operational thread connecting five RFCs associated with Jeffrey Haas. The thread begins with managed entities for BGP peer state in RFC 4273, moves down to independent failure detection on members of a link aggregation group in RFC 7130, then returns to BGP to distinguish graceful notification handling from a hard reset in RFC 8538. RFC 9384 adds a specific reason when BFD causes a BGP connection to terminate. RFC 9774 addresses a different kind of failure state: not a dead link or session, but path data whose unordered segments leave important routing meaning ambiguous.

Haas is not the sole author of this sequence, and it should not be read as a claim that one person designed or controls BGP, BFD, IETF consensus, implementations, deployments, or operational results. The RFCs have different combinations of editors and authors, emerged through IETF review, and depend on implementers and operators to become running behavior. Haas’s IETF profile provides the person-level connection: it lists roles in the Bidirectional Forwarding Detection and Inter-Domain Routing groups and records his association with the RFCs examined here.

The analytical value lies in the continuity of the problems, not in turning collaborative standards work into a heroic biography.

The common discipline is to move from vague failure toward bounded evidence. What state was observed? At which layer? Was it desired state or running state? Did a signal cross the failed path, or was it recorded only locally? Does a notification explain the trigger or establish the root cause? Is retained routing information constrained by a deadline? Can a path be interpreted consistently when its contributors change? Those questions define the limits of operational authority. A record can support a decision, but it cannot substitute for the forwarding state that the network actually exhibits.

RFC 4273: making BGP peer state inspectable

RFC 4273, edited by Haas and Susan Hares, defines managed entities for BGP-4. It is deliberately modest about its own scope. The document says it records deployed implementations in a historical context, clarifies earlier work, corrects errors introduced during conversion to a newer management language, and notes places where the module does not fully represent BGP. That warning matters. The RFC is an instrumentation boundary, not a claim that a management view is complete.

The BGP Peer Table supplies one entry per peer connection. Its bgpPeerState entity records the finite-state-machine state; other entities cover desired administrative status, counts of updates and total messages in both directions, the last BGP error, the number of transitions into Established, the time in or since Established, negotiated and configured timers, and elapsed time since the last update. Together, those fields make a session legible as a changing operational entity rather than a binary label. An operator can distinguish a peer that is administratively stopped from one that is attempting to connect, observe repeated transitions, correlate the latest error with current state, and compare activity with timer state.

The distinction between actual and desired state is especially important. The peer-state entity reports the connection’s finite-state-machine state. The administrative-status entity expresses whether the connection is intended to start or stop, and changing it can generate manual start or stop events. RFC 4273 warns that write access requires adequate authentication because a management action can restart or terminate peer connections.

The same document explains that careless changes to retry, hold, keepalive, origination, or advertisement intervals can make sessions fragile, delay restoration, disrupt connectivity, or contribute to routing loops and blackholes. Observability and control share an interface, but they are not the same power.

The counters carry another lesson in evidence discipline. Earlier wording suggested that several message counters should be initialized to zero when the session entered Established. RFC 4273 removes that suggestion and explicitly warns applications not to assume the counters started at zero. A number without lifecycle context is not a trustworthy rate, incident boundary, or proof of causation. The notification entities follow the same logic: one event reports entry into Established, while another reports a backward transition in the state machine; both include peer identity, last error, and state. The event identifies a boundary crossing.

It does not explain everything that happened before or after it.

RFC 4273 also separates received path attributes from the attributes that actually participate in route selection after local policy. That separation prevents a management record from being mistaken for forwarding truth. A received attribute table is evidence about input state. The locally used route is a product of additional decisions. Even a correctly implemented management interface therefore needs correlation with current configuration, policy, session history, and forwarding observations.

The expected result of this RFC is inspectability: common names and types for peer state, activity, timers, errors, transitions, and received path information. Its failure modes remain explicit. An implementation may expose an incomplete view; an operator may not collect the entities; counters may be interpreted without their lifecycle; access may be inadequately protected; or a writable entity may be changed by an unauthorized principal. Nothing in the RFC establishes universal collection, accurate implementation, or better incident outcomes. It establishes the record surface on which those practices can be built.

RFC 7130: locating failure inside a link aggregate

RFC 7130, edited by Manav Bhatia, Mach Chen, Sami Boutros, Marc Binderberger, and Haas, moves the boundary below the BGP session. A link aggregation group presents several physical links as one logical interface. That abstraction provides capacity and resilience, because traffic can continue over remaining members when one member fails. It also hides detail. A single BFD session over the aggregate, without knowledge of its members, cannot guarantee detection of an individual member-link failure.

The RFC’s decision is to run an independent asynchronous BFD session on every LAG member link. It calls these micro-BFD sessions. Each session has its own discriminator values, state variables, state machine, and potentially its own timers. The design makes member continuity independently observable. It can complement LACP, operate where LACP is absent, and test aspects of bidirectional Layer 3 forwarding rather than relying only on a lower-layer indication. The document presents shorter detection than LACP as a property of the mechanism, but it does not report a deployment study or measured restoration result.

Several alternatives and exclusions sharpen the decision. Native Ethernet mechanisms can detect some failures, and LACP already provides per-member functions. Operators that use BFD across other technologies may prefer one failure-detection method across those environments. The RFC covers asynchronous BFD but leaves the echo function outside scope. It allows IPv4 or IPv6 sessions and permits both on a member, while requiring a consistent address-family choice across the members of a given aggregate.

A dedicated destination distinguishes micro-BFD traffic from ordinary single-hop BFD, limiting a class of ambiguity when the two ends are configured differently.

Detection becomes consequential through the load-balancing boundary. Even if LACP regards a member as ready, the member must not be selected for ordinary load balancing until the relevant micro-BFD sessions are Up. When a micro-BFD session goes Down, the member must be removed from the applicable load-balancing table. Where an implementation keeps separate IPv4 and IPv6 tables, it may remove the member only for the failing address family or remove it from both; the RFC leaves that choice to the implementation.

Layer 3 protocols that see only the aggregate receive the effect indirectly through the changed load-balancing table or through a separate decision to take down the aggregate.

This design does not turn every Down state into proof of a broken cable. It defines how one failure detector influences eligibility for forwarding. Provisioning and deprovisioning create edge cases. If micro-BFD is enabled after an already active member is carrying traffic, its state should not affect load balancing until the session first reaches Up, so the order of enabling the aggregate and enabling BFD does not itself interrupt service. If the feature is removed while the session is Up, the session should move to AdminDown and attempt to communicate that change.

An AdminDown state, local or remote, should not be treated as a connectivity failure or automatically remove the member.

The appendix exposes a harder failure mode: one device may run micro-BFD while the other does not. The configured side can see the session as Down while the other side holds a different view of link health, a mismatch likely to cause traffic loss across the aggregate. A separate bootstrap method could detect the mismatch, but such a method is outside the RFC’s scope. The document also permits a configurable timeout for a member that forwards before BFD reaches Up, while requiring that the timeout can be disabled. This is a choice between avoiding an indefinitely inconsistent state and avoiding a premature removal during initialization.

For operators, RFC 7130 turns “the aggregate is up” into a more precise question: which members are eligible, for which address family, according to which independent session, and at what point in the feature lifecycle? Its expected result is a narrower failure domain and a defined action at the load-balancing boundary. Its unresolved questions belong to implementations and deployments: timer selection, bootstrap, address learning, per-family behavior, hardware support, and the correlation of BFD state with physical and forwarding evidence.

RFC 8538: distinguishing graceful handling from a hard reset

RFC 8538, authored by Keyur Patel, R. Fernando, John Scudder, and Haas, addresses ambiguity at a BGP session reset. The original graceful-restart behavior did not apply its procedures when a BGP NOTIFICATION was sent or received. The 2019 RFC adds a capability flag indicating support for graceful handling of notifications. When both peers have exchanged that support, notifications other than a Hard Reset invoke graceful-restart semantics. A Hard Reset instead tells the peer to terminate the session fully.

This distinction matters because the same observable event—a BGP session reset—can imply opposite treatment of previously learned routes. Under graceful handling, a receiving speaker retains covered routes and marks them stale while the session restarts. Under a hard reset, it follows the ordinary full-termination procedure. The new Hard Reset subcode is therefore a boundary around intent. It tells the receiver not to infer that a notification should preserve state merely because graceful-notification support was negotiated.

The Hard Reset carries the underlying error information inside it. That design preserves two layers of meaning: the outer signal directs full termination, while the enclosed error code, subcode, and associated data retain the reason. If a peer has not advertised support for the extension, a speaker should not send the Hard Reset. The RFC notes that doing so would still reset the session under existing BGP behavior, but the peer might be unable to log the associated information correctly. Compatibility can preserve the action while losing the explanation.

The document also refuses to turn every implementation condition into a universal reset rule. It offers suggested treatment for existing Cease reasons, associating permanent or long-lived conditions with hard reset and several potentially transient conditions with graceful handling. Administrative reset is left under user control. These are suggestions, not requirements, because an implementation’s internal states do not always map neatly to BGP notification codes. The guiding principle is whether forwarding has a realistic chance to continue and whether the session can return before the retention deadline.

That deadline is central. RFC 8538 makes a configurable stale timer mandatory and suggests a default of 180 seconds. An implementation may offer infinite retention, but it must not make that the default. The timer bounds the period during which stale routes can survive. This is both an operational and a security constraint: because the extension relaxes earlier protection against consecutive resets, an attacker might otherwise use repeated resets to keep stale routes from being deleted indefinitely. The RFC is careful not to promise generalized resilience, noting that deployment-specific factors prevent broad claims.

A second state bit matters when the session returns. Both speakers should indicate that forwarding state was preserved; if they do not, the relevant routes are flushed under the graceful-restart procedure, defeating the extension’s purpose. Again, the specification defines the signal and required behavior, but the outcome depends on implementation correctness and actual forwarding continuity. A speaker can advertise capability, retain routes, and still face a data-plane condition that the control-plane exchange does not reveal.

RFC 8538 therefore adds a choice that is both more expressive and more dangerous if used carelessly. Graceful treatment can avoid unnecessary route removal during a recoverable control-plane interruption. Hard reset can prevent inappropriate preservation when continuity is not realistic. Excessive retention can prolong stale state; excessive hard resets can remove state that might have remained usable. The standard supplies bounded semantics. It does not choose the right answer for every failure.

RFC 9384: attributing termination to BFD

RFC 9384 narrows the explanation one step further. The RFC, authored by Haas and published through the IETF standards process, defines “BFD Down” as a BGP Cease notification subcode. When a BGP connection is terminated because the associated BFD session enters Down, the BGP speaker should send a Cease notification carrying that reason, if communication is still possible.

The mechanism makes a clean separation between detection and action. BFD detects loss of connectivity between forwarding engines and provides an advisory signal to clients. BGP is one such client. BGP decides to terminate its connection rather than waiting for its own hold timer, and the notification records that BFD supplied the trigger. The subcode does not make BFD the controller of the BGP finite state machine, and it does not establish why the BFD session went Down.

Partial and total loss create different evidence. With partial connectivity, the remote speaker may still receive the Cease notification and learn that the connection is closing because of a BFD-detected issue rather than a BGP-speaker error. With total loss, the failed path may prevent the notification from being sent at all. RFC 9384 therefore says the local speaker should still preserve the reason in operational state. It explicitly points back to the last-error entity from RFC 4273 as one place where that reason can appear.

The sequence closes a long arc: a management field defined in 2006 becomes a place to retain a more specific failure attribution defined in 2023.

RFC 9384 also composes with RFC 8538. If the hard-reset procedure is required and BFD caused the termination, the BFD Down reason should be enclosed within the Hard Reset. The outer signal controls whether the peer preserves or flushes state; the inner signal identifies the immediate trigger. That layering prevents “full termination” and “BFD detected loss” from collapsing into one overloaded code.

The limits are as important as the new information. The RFC describes the subcode as purely informational and says it adds no finite-state-machine effect beyond existing BGP behavior. Operators choose BFD timers by balancing stability against fast failure detection. A Down transition may reflect partial connectivity, and a delivered notification may not reveal the underlying physical, forwarding, configuration, or peer condition. A missing notification may mean the path was too broken to carry it, not that BFD was uninvolved. Correlation with local BFD history, interface state, peer logs, and forwarding observations remains necessary.

The authorship context also resists a simple inventor narrative. RFC 9384 acknowledges reviewers, Routing Directorate input, and a substantively similar proposal written years earlier by Bruno Rijsman that did not progress at the time. The eventual RFC has one named author, but its status comes from the IETF process and accumulated work. The operational contribution is the standardized reason code and its boundaries, not personal ownership of the behavior that implementations may later provide.

RFC 9774: removing ambiguous path state

RFC 9774, authored by Warren Kumari, Kotikalapudi Sriram, L. Hannachi, and Haas, turns a prior recommendation against AS_SET and AS_CONFED_SET into a standards requirement. These are unordered AS_PATH segment types created during route aggregation: AS_SET can contain autonomous systems traversed by contributing routes, while AS_CONFED_SET serves a similar role for member autonomous systems inside a confederation. Their unordered form obscures a property operators and security mechanisms need to interpret consistently: which autonomous system is presented as the route’s origin.

The document’s primary operational move is prohibition with a transition boundary. Unless an operator explicitly configures otherwise, such as during a transition, BGP speakers must not advertise updates containing either unordered segment type. On receipt of an update containing one in AS_PATH or AS4_PATH, a speaker must apply treat-as-withdraw behavior. This does not prove that every implementation or network has changed. It defines the required default and preserves a bounded exception for transition.

Removing the unordered sets solves one ambiguity but exposes decisions that the old construct sometimes concealed. Traditional aggregation combines multiple more-specific routes into one less-specific route. When implementations perform what RFC 9774 calls brief aggregation, they omit the set and keep the longest leading sequence common to the contributing paths. The resulting origin can change as contributing routes appear or disappear. A route that looks unambiguous at one instant may present a different rightmost autonomous system after the input set changes.

The RFC’s answer is consistent brief aggregation. The implementation is configured to truncate the path after the rightmost occurrence of a selected, stable origin for the aggregate. If that truncation removes path information that ordinary aggregation would otherwise retain, the aggregate should carry the ATOMIC_AGGREGATE attribute. The point is not to pretend that no information was lost. It is to replace unordered, variable meaning with an explicit origin decision and metadata indicating aggregation.

That decision carries forwarding consequences. The old set could cause a contributing autonomous system to reject an aggregate because it saw itself in the path, providing a form of loop protection. Without the set, a contributing network may accept the less-specific route and create the conditions for a forwarding loop. RFC 9774 therefore says an aggregate should not be advertised back to contributing autonomous systems; they should instead receive appropriate more-specific routes. It also reiterates that the router generating an aggregate must discard traffic that matches the aggregate but none of the installed more-specific routes.

Removing ambiguous metadata does not remove the need for loop prevention; it moves that responsibility into explicit filtering and forwarding behavior.

The RFC discusses routing-security mechanisms as a beneficiary of clearer origin semantics, but that is not the center of this operational sequence. The more general point is that a path record must have stable meaning as its inputs change. An unordered collection that cannot identify a consistent origin is weak evidence for any downstream decision. Prohibiting it narrows allowed state, while consistent aggregation, explicit aggregation metadata, filtering, and discard behavior define the replacement responsibilities.

Expected results must remain bounded. The standard simplifies allowed BGP behavior and makes origin semantics clearer. It can reduce the amount of implementation logic associated with the deprecated segment types if that code is actually removed. It does not establish that old paths have disappeared, that every speaker supports the requirement, or that transition is risk free. Treat-as-withdraw can affect reachability when legacy updates remain. Incorrect consistent aggregation can still produce an unintended origin. Incorrect filtering or missing discard behavior can still produce loops.

The standard removes one ambiguity; it does not automate all the decisions that ambiguity had been masking.

A sequence of operational handoffs

Viewed together, the five RFCs define handoffs rather than a single control system. RFC 4273 hands observed BGP state to management. RFC 7130 hands a member-level BFD state to the component deciding forwarding eligibility within an aggregate. RFC 8538 hands reset intent to a peer and binds retained state with a timer. RFC 9384 hands a BFD-attributed termination reason to the peer when possible and to local operational records when it is not. RFC 9774 hands aggregation responsibility from an unordered path construct to explicit origin, metadata, filtering, and discard decisions.

Each handoff has a loss mode. Management data can be incomplete or misread. A micro-BFD session can be mismatched across peers. A hard-reset signal can reach a peer that cannot log its enclosed reason. A total failure can prevent the BFD Down notification from crossing the path. Stale routes can survive too long if retention is configured carelessly. An aggregate without unordered sets can loop if contributing networks receive it or if unmatched traffic is not discarded. Better vocabulary does not eliminate failure; it makes failure modes separable enough to test and govern.

The sequence also demonstrates why uniqueness and accuracy matter for routing signals. A peer-state value should not be conflated with administrative intent. A member-level session needs its own identity and state machine. Graceful and hard termination need distinct semantics. A termination reason needs to be carried separately from the action it accompanies. An aggregate origin needs stable meaning instead of an unordered set. In every case, ambiguity expands the authority of whoever interprets the state, because that interpreter must guess. More precise state constrains that discretion.

Reversibility appears in different forms. A member can re-enter load balancing after its independent session is Up. Graceful restart retains routes only within a bounded period. A hard reset explicitly rejects retention when continuity is implausible. A transition exception allows operators to move away from deprecated path segments deliberately rather than pretending legacy state does not exist. These are not identical rollback mechanisms, but they share a preference for actions whose scope and exit conditions can be understood.

Time is another boundary carried across the sequence. RFC 4273 exposes negotiated and configured timers while warning that careless changes can destabilize sessions or delay recovery. RFC 7130 permits independent micro-BFD timers, even within one aggregate, although common values are expected. RFC 8538 adds a separate stale-route deadline, preventing graceful retention from silently becoming permanent. RFC 9384 reminds operators that BFD timer choices trade faster detection against stability.

RFC 9774 does not define a failure timer, but its explicit transition exception creates a policy interval during which old and new path behavior may coexist. These clocks should not be collapsed into one “convergence” number. One measures peer liveness, another member continuity, another the credibility window of retained routes, and another the duration of a migration choice. Their interaction may shape an incident, but the RFCs do not supply a universal optimal setting. The operational task is to document which clock expired, what action it authorized, and whether the observed forwarding result matched that action.

Requirements are not deployment evidence

Standards language describes what a conforming implementation must, should, or may do. It does not reveal whether a particular device supports the function, whether an operator enabled it, whether two peers negotiated the same capability, whether timers suit the topology, or whether the forwarding plane matched the control plane during an incident. That distinction is especially important in a people article, where publication dates and named authors can tempt the reader to infer real-world effects that the sources do not measure.

RFC 4273 defines entities but does not prove collection. RFC 7130 defines per-member sessions but does not prove hardware coverage or restoration time in a deployed aggregate. RFC 8538 defines capability negotiation, route retention, and hard reset but expressly avoids general resilience claims. RFC 9384 defines an informational reason and no new state-machine action. RFC 9774 defines prohibited path forms and replacement practices but does not certify a completed Internet-wide transition. The honest result statement is narrower: these RFCs improve the standardized representation and handling of particular failure states.

Adoption can also be nonuniform within one path. One peer may support graceful notification while another does not. One side of an aggregate may run micro-BFD while the other is misconfigured. A speaker may recognize BFD Down locally but be unable to send it over a failed connection. A network may stop originating unordered sets while continuing to receive them from a legacy neighbor. Operators therefore need evidence at both ends of each boundary: advertised capability and received capability, configured session and observed session, sent reason and received reason, originated path and accepted path.

Measured outcomes require a separate layer of evidence: timestamped events, configuration history, packet or forwarding observations, device behavior, and a defined comparison period. None of the six official sources used here supplies incident-reduction data, customer results, commercial performance, or a universal convergence measurement. It would be inaccurate to attach those outcomes to Haas or to the RFCs. The documents support analysis of mechanisms, requirements, alternatives, and risks.

What operators can do with the discipline

The first implication is to preserve distinctions in operational tooling. State dashboards should keep desired administrative state separate from observed protocol state. Counters should carry reset and collection context. A BGP termination should retain both the action taken and the immediate trigger. BFD Down should be treated as an attribution to a detector, not as a final root-cause category. Route aggregation views should expose the selected stable origin, aggregation metadata, contributing routes, and the loop-prevention behavior that replaces unordered sets.

The second implication is to test transitions, not only steady states. For micro-BFD, that means examining initial enablement, a member moving Down, an administrative disable, a peer-side mismatch, and address-family-specific behavior. For graceful notification, it means testing capability asymmetry, delivery of an ordinary notification, delivery of a hard reset, expiry of the stale timer, and failure to preserve forwarding state when the session returns. For BFD-attributed BGP termination, it means comparing partial loss, where a notification might arrive, with total loss, where only local state may record the reason.

The third implication is to keep the authority of automation bounded. A management interface capable of changing peer status or timers needs stronger protection than a read-only view. A BFD state can remove a member from load balancing, but its administrative lifecycle must not masquerade as physical failure. A stale route can support continuity, but only within an explicit retention policy. Treat-as-withdraw protects against a prohibited path form, but transition planning is necessary where legacy advertisements remain. Automation is safest when its input, permitted action, deadline, and recovery condition are all visible.

The fourth implication is organizational. Standards authors and working groups can define common semantics. Implementers decide how those semantics enter software and hardware. Vendors expose capabilities and operational state. Operators select timers, enable features, coordinate peers, protect management access, and validate forwarding. Reviewers and later RFC authors connect mechanisms across time. Incident evidence finally determines what occurred in one network. No entity can legitimately claim the authority of all the others.

Attribution without personal control

Haas’s profile and the five RFCs support a precise person-level statement: his attributed standards work repeatedly engages with how routing systems represent and constrain failure state. RFC 4273 was edited with Susan Hares and built on earlier MIB work by other authors. RFC 7130 has five named editors. RFC 8538 has four named authors. RFC 9384 acknowledges both collaborative review and earlier similar work. RFC 9774 has four named authors. Each standards-track document represents IETF community review rather than unilateral publication.

That record is meaningful without being inflated. It shows sustained participation at the interfaces between routing state, failure detection, notification, management, and path semantics. It does not show that Haas selected operator timers, wrote every implementation, controlled working-group consensus, directed deployments, or produced a measured network result. The most faithful account of leadership here is contribution to bounded language: define what was observed, distinguish it from what was intended, identify the allowed response, retain enough reason for later diagnosis, and state what remains outside scope.

The unresolved questions are therefore not defects in a personal story. They are the remaining work of running networks. How should a particular operator balance BFD speed and stability? How long can stale routes remain credible in a specific topology? Which evidence should override a delivered reason code when the forwarding plane disagrees? How should a mixed network phase out unordered path segments without avoidable reachability loss? The RFCs make those questions more answerable by refusing to pretend that one signal, one author, or one layer owns the whole outcome.