Summary

  • RFC 8966, co-authored by Juliusz Chroboczek and David Schinazi, treats Babel link-cost and metric computation as local policy. Its essential shared condition is strict monotonicity: when a node adds its local cost to an advertised metric, the resulting metric must be greater; an infinite local cost produces an infinite result.
  • That condition protects a loop-avoidance argument. It does not make every metric a comparable statement about a route’s capacity, price, physical delay, current reachability, user experience or service outcome. RFC 9616 makes the boundary visible: even accurate RTT samples can be too noisy to feed directly into route selection, and their use is limited to environments where symmetric delay predicts the relevant choice.

The number has a job, not a mandate

Engineers often inherit a dangerous habit from dashboards: a number placed next to a route begins to look like a verdict on the route. Lower appears better. A value that moves appears to report the condition of the network. A metric that is exported appears to invite comparison across routers, implementations and domains. None of those readings follows automatically from a routing protocol.

RFC 8966 begins with a narrower construction. Babel is a loop-avoiding distance-vector protocol. A node receives a neighbour’s advertised metric and computes a route metric with a locally computed link cost. The document does not prescribe one worldwide formula for that computation. It says metric computation is a local policy matter and expressly allows different nodes in the same network, and different interface types, to use different strategies.

The common rule is not that every node must measure the same thing. It is that the operation must preserve the property the protocol needs. If local cost is infinite, the resulting metric is infinite. Otherwise the computation must be strictly monotonic: adding the local step produces a value greater than the advertised value. The restriction is technical and exact. It helps ensure that a forwarding choice cannot keep walking around a cycle while claiming that it has not become worse.

That is the kind of minimum common layer worth defending. It gives independently operated nodes a condition they can apply to their own calculation. It does not appoint an institution to interpret every score, or turn one implementation’s route ranking into a general statement about what a network, customer or market should prefer.

Loop-safe is not globally optimal

RFC 8966 draws a second line that is easy to lose in a simplified explanation. It says that left-distributivity is recommended but not essential to loop-free convergence. Where that property is absent, Babel can still converge without loops, but might not reach a global optimum; indeed, a global optimum might not exist.

The wording matters. A network can retain the safety invariant while giving local policy room to value a link differently. The result might be appropriate for the topology and interfaces in front of that operator, yet not be a universal ranking of every imaginable path. A metric can be useful precisely because it is situated.

Route selection adds further discipline. A Babel node must not select an infinite or unfeasible route. It must not prefer a route merely because its sequence number is higher: RFC 8966 warns that this can create oscillation and, with some metric choices, persistent black holes. When metrics vary continuously, the RFC recommends hysteresis so that a route does not switch merely because an instantaneous value flickered below another.

These are safeguards against a particular kind of overreaction inside the routing process. They do not show that the selected route is carrying traffic at this moment, that a remote service answers, that the path has a certain price or that the number measures a customer’s experience. A selected entry is a bounded claim about the decision mechanism that selected it, under its own inputs and assumptions.

Measurement still needs a translation rule

RFC 9616, co-authored by Baptiste Jonglez and Chroboczek, shows why the distinction is practical rather than philosophical. It says RFC 8966 does not mandate a particular metric algorithm. The newer RFC defines a delay-based extension because packet-loss and hop-count practices can choose poorly in some tunnel or VPN topologies.

Its example is deliberately concrete: routes that look equal under an existing metric can differ sharply in where the tunnel endpoint lies. Yet the RFC does not elevate raw RTT into the truth of the network. It says the RTT samples may be accurate but noisy; used directly, they can create feedback and frequent oscillation. The document therefore defines a mapping from samples to link cost and a hysteresis treatment. It also limits its applicability to environments where symmetric delay is a good predictor of whether a link should carry routing traffic.

An observation is not a decision rule merely because it is measured accurately. A decision rule is not a service guarantee merely because it is stable. Keeping those stages separate is how an operator can explain what the number means, where it was observed, how it was transformed and why it influenced a route choice.

Flexibility has documented limits

RFC 8965, authored by Chroboczek, presents Babel’s weak assumptions as a source of robustness with unusual or fluctuating metrics. It also records limits that a promotional reading would erase. Periodic updates make Babel less suitable for some large stable or low-power environments; its design assumes routers can hold a full routing table. The RFC describes useful deployment niches, not a claim that one routing protocol or one metric fits every network.

Chroboczek’s IETF Datatracker profile lists RFCs 8965, 8966 and 9616 among his published work. That supports a bounded personal thread through the documents. It does not establish sole authorship of the protocol, control over a running Babel domain, or authority to decide how a particular operator should value delay, loss, energy, cost or continuity.

The same boundary applies to the authorship record and to the metric. An RFC can make a safety condition public. An operator still owns the local implementation, the topology, the measurement method and the consequences of forwarding. Running evidence—not a number’s appearance in a specification—shows what has actually been adopted.

Evidence limits

The sources do not identify a current Babel deployment, a live tunnel, a selected route in any named network, a capacity value, a price, a current RTT, a security posture or a service result. They do not prove that any local metric is best for all topologies. They do not make a route advertisement a promise that traffic will arrive.

The proposed metric receipt is an editorial inference from the protocols’ boundaries: record the metric family and version, local input scope, transformation and hysteresis, feasibility and selection state, measurement interval where relevant, and the topology or interface assumptions. That receipt does not make a local number globally authoritative. It makes the number reviewable where it actually operates.

Sources