Summary

  • RFC 4098 calls a BGP device converged when it has completed the control-plane actions required by the stated test. RFC 7747 sets a different finish line: all FIB changes are complete and all forwarded test traffic takes the newly proposed route.
  • Susan Hares is a co-author of both Informational RFCs, not their sole inventor or the owner of any deployment. Their joint lesson is evidentiary: every convergence number needs a named event, layer, route population, policy, load, measurement interval and path back.

The route announcement that arrived before the packets

Suppose an external BGP peer withdraws the path currently selected for a set of prefixes. An alternate route is already available. The device under test receives the change, applies import policy, chooses a new best route, updates its Loc-RIB and advertises the result. A control-plane observer can put a stop time on that sequence.

Traffic may still be using the old adjacency, waiting for a FIB download, falling through a transient gap or moving prefix by prefix. Some packets can arrive on the new path while others are lost, duplicated or reordered. The BGP process may have no further work to report even though the forwarding consequence is unfinished.

Neither clock is fraudulent. They answer different questions. The error begins when a label from the shorter chain is used to certify the longer one.

RFC 4098 was written for the first question. Published in 2005 by Howard Berkowitz, Elwyn Davies, Susan Hares, Prakash Krishnaswamy and Michael Lepp, it standardised terminology for eBGP convergence in the control plane of a single device. Its initial field of view is the arrival, processing and propagation of routing information. Under a stated test condition, the device has converged when it has performed the required control-plane actions. For a best-route change affecting one prefix, the document gives advertising the new route to downstream peers as an example of completion.

That is a meaningful end point. It reveals how quickly the routing process absorbs and propagates a change. It just does not establish that the forwarding plane has caught up.

A second finish line outside the router's explanation

RFC 7747, published in 2016 by Rajiv Papneja, Bill Parise, Susan Hares, David Lee and Ilya Varlashkin, takes the next measurement from packet evidence. It defines FIB or data-plane convergence as the point at which all FIB changes are complete so that all forwarded traffic takes the newly proposed route. It explicitly says that this differs from control-plane convergence inside a node, and places control-plane test methodologies outside its own scope.

The phrase “all forwarded traffic” needs its test boundary. It does not mean every packet on the Internet. It means the offered traffic for the routes, topology and event declared by the benchmark. The method uses a single BGP device under test and simple three- or four-node arrangements for iBGP, eBGP and eBGP multihop cases. This is an intentionally controlled laboratory, not a miniature claim about every route reflector, line card, tunnel, recursive next hop and traffic-engineering policy in a production network.

The tester keeps sending packets while the route change occurs. Observed loss supplies the time estimate. That makes the packet interval a hard limit on accuracy: if a particular route receives one test packet every ten milliseconds, the method cannot locate its recovery to a finer instant merely because a software counter prints microseconds. The instrument's cadence is part of the result.

The reporting matrix protects the number from becoming folklore. It asks for the topology and event, eBGP and iBGP sessions, peer and route counts, unique and repeated routes, route mixture, route packing, policy, interface type, packet size, offered load, sampling interval, timers and TCP parameters. It also records security features that may change processing. For the initial event and its reversion, it separates packets offered and forwarded from connectivity loss, convergence loss, out-of-order packets and duplicates.

One scalar cannot carry all of that meaning. A “400 ms convergence” claim without its route population and packet interval is not a compact benchmark. It is an orphaned number.

Route mixture is part of the question

RFC 4098 had already warned that the input is not neutral. A route mixture includes the distributions of path lengths, attributes and prefix lengths, the way routes are packed into UPDATEs, and the timing pattern of those UPDATEs. A table of identical simple prefixes asks one question about the device. A mixture shaped to resemble live arrivals asks another. The RFC called realistic modelling an open research problem rather than pretending that “a full table” is one universal workload.

Policy changes the workload again. A minimal accept-and-advertise configuration may expose raw processing limits. A production-like policy can filter many prefixes, modify attributes or create different best-path outcomes. RFC 7747 therefore requires a baseline using minimal policy and documentation of any additional policy. Peer count, routes per peer, MRAI, MAOI, hold and keepalive timers, TCP behaviour, authentication, route-security processing and interface failure detection can all move the result.

Repeatability is not achieved by rerunning an unexplained configuration. Optional settings should be disabled and defaults used unless the test says otherwise. When trials are averaged, the parameters must remain the same. Timer expiry and CPU scheduling introduce variation, so the average belongs with the trial count, spread and an honest account of statistical significance.

This is where the two clocks become an operational discipline rather than a protocol anecdote. The control-plane trace needs the exact incoming event and the point at which route processing and propagation ended. The data-plane trace needs the same event identity, the relevant prefix population, the FIB transition and the packet observation. Without a common event key, two attractive graphs may be measuring different failures.

The method came through more than one protocol

RFC 7747 did not invent packet-observed convergence in isolation. Its reporting format uses the rate-derived method from RFC 6412, a terminology document for link-state IGP data-plane convergence. RFC 6412 describes externally observable, black-box measurement; RFC 6413 develops loss-derived, rate-derived and route-specific methodologies. Those documents do not become BGP requirements by citation. They supply measurement ancestry: observe what leaves the device rather than asking an internal process to certify its own external effect.

The longer benchmark lineage includes RFC 1242's terminology and RFC 2544's laboratory pattern in which a tester sends traffic through a device and verifies what returns. Again, inheritance must be bounded. RFC 2544 does not by itself prove BGP failover, and a clean lab does not forecast a distributed service. It supplies controlled method, not a transferable service-level promise.

RFC 4271 supplies the protocol substrate. BGP exchanges reachability information, maintains received, selected and advertised routing information, and applies policy at the AS level. An UPDATE can be valid, a Loc-RIB can settle and an Adj-RIB-Out can be ready while the hardware consequence is still being installed. The separation is not an implementation embarrassment. It is an architectural fact worth measuring.

Susan Hares as a bounded thread

The current IETF Datatracker page identifies Susan Hares, also known as Sue Hares, and lists her as an IDR chair and secretary of the BGP Directorate. It lists seventeen RFCs, including RFC 4098 and RFC 7747. The page also provides the public photograph used to ground the accompanying AI editorial portrait.

That record supports a precise human claim. Hares participated in two collective documents that, across eleven years, distinguish how routing convergence is described from how forwarding convergence is tested. It does not show that she alone devised either method, that the later RFC was her predetermined programme, or that she controls an IETF consensus, a vendor implementation or an operator's network.

The other authors matter because benchmark credibility is collective work. So do implementers who expose clocks accurately, test engineers who hold conditions constant, operators who reproduce relevant route mixtures and service owners who decide whether packet loss is acceptable. An RFC author supplies a public method; the party running the network bears the decision and the consequence.

What a defensible convergence record contains

A useful incident or qualification record connects at least seven observations:

  1. The triggering event is timestamped and named: withdrawal, announcement, link failure, hard reset, soft reset or another reproducible condition.
  2. Adj-RIB-In evidence identifies which routes and attributes reached the BGP process.
  3. Policy output and best-path reasoning show what entered the Loc-RIB and why.
  4. Propagation evidence records when required control-plane work ended, without calling that packet recovery.
  5. FIB instrumentation shows which prefixes and next hops were programmed and when.
  6. External traffic measurement records the offered population, loss, duplicates, reordering and sampling limit.
  7. The reversion event demonstrates that the system can return, using the same condition ledger and evidence chain.

The record may reveal a small gap, a large gap or no resolvable gap at the chosen sampling interval. Any of those can be a valid result. What is invalid is deleting the distinction because one dashboard has only one field named convergence_time.

The two clocks therefore offer a modest rule for infrastructure claims. Stop each timer where its evidence stops. A route advertisement proves an advertisement. A FIB acknowledgement proves what that implementation defines it to acknowledge. Packets prove the bounded traffic observations made at the declared cadence. Reliability begins when those claims are linked—and none is promoted beyond its authority.

Sources