Summary

  • Under RFC 9843, a maximum Generic Metric leaves a link in the Flex-Algorithm calculation as a last resort; it is not a withdrawal.
  • If the winning algorithm requires a non-IGP metric that the link does not advertise, the link is pruned. But missing bandwidth or delay evidence does not, by itself, prune that link under the corresponding threshold constraint.
  • The defensible record is not “metric bad”. It is the winning definition, field-presence state, raw or derived value, consuming rule, ordered pruning result, calculated topology and later running-state evidence.

The maintenance instruction sounded unambiguous: push every link on the router to the highest metric so traffic leaves it. Most traffic did. One flow did not.

Nothing in that hypothetical requires a defective router. If no shorter path exists, a maximum usable metric can preserve the link as a last resort. The operator asked for de-preference and mentally translated it into removal. The protocol did not. A dashboard that paints the number red may reinforce the same mistake: severity is a presentation choice; membership in the calculation is a rule.

The inverse mistake is just as easy. An empty metric may be read as “unknown, keep going”, yet the selected algorithm can require the link to be pruned. Another empty field—a missing bandwidth or delay observation used only by a constraint—can produce the opposite interim result: do not prune on that rule; continue to the next one. The bytes are absent in both cases. Their authority is not.

RFC 9843, published on the Standards Track in September 2025 and recorded separately by the RFC Editor, updates RFC 9350. The plain-text and XML editions define generic metrics, minimum-bandwidth and maximum-delay constraints, a Bandwidth Metric, and automatic metric calculation for IS-IS and OSPF. That publication establishes common semantics. It does not establish adoption, a configured algorithm or a path in any live network.

Three states, not one alarm

The central distinction can be stated without a topology diagram.

Input state Rule consuming it RFC 9843 result at that rule
Maximum usable Generic Metric Shortest-path cost Retain the link as a last resort
Selected non-IGP metric absent Metric availability rule Prune the link; do not assume zero
Bandwidth or delay evidence absent FAEMB or FAEMD constraint Do not prune on that constraint; apply later rules

These are not policy suggestions that an implementation may blend. They are distinct inputs to distinct deterministic procedures. They also do not finish the causal chain. A retained link may lose under cost, a link that survives one constraint may be removed by another, and a calculated route may never enter the forwarding table. The table describes one decision boundary at a time.

That discipline follows the minimum-common-layer argument in docs/heng-lu-note.md. Independent routers need identical meanings for the fields they exchange and the order in which they consume them. They do not need a central institution to choose an operator's traffic classes or maintenance policy. The standard makes the shared rule exact; each participant validates and calculates locally. Running state, not publication, supplies the outcome.

The maximum is deliberately still usable

RFC 9843 defines a Generic Metric per link and metric type. In IS-IS, 0xFFFFFF is the maximum usable metric; in OSPF, 0xFFFFFFFF has that role. A link carrying the maximum value remains available as a last resort under the RFC 9350 calculation model.

This is operationally useful. Setting a very high metric before maintenance can divert traffic to shorter alternatives without creating immediate disconnection when the network has no alternative. The RFC says precisely that traffic can stay on the router when no alternate path exists because maximum-metric links are not removed from the calculation.

It is also a dangerous place for shorthand. “Drained”, “maintenance”, “red”, “infinite” and “maximum” are not synonyms. A maintenance system that promises isolation after writing a maximum metric overstates its action. A change receipt should say: which metric type was written, to which link advertisements, under which winning Flexible Algorithm Definition, at what value, and whether an alternative calculation actually excluded the node from selected paths.

If removal is required, the evidence must show a removal mechanism. RFC 9843 points to omission of the metric type used by the algorithm as one way to make a link unusable for that calculation. Other controls may exist in the wider routing system, but a high cost alone is not proof of withdrawal.

The missing selected metric closes the path

RFC 9350's ordered pruning procedure states that when a Flexible Algorithm uses a metric other than the ordinary IGP metric, a link that does not advertise that metric is pruned; an implementation must not pretend the missing value is zero. RFC 9843 carries that rule into its new Generic Metric types.

The reason is semantic, not cosmetic. A shortest-path calculation can compare costs only when the cost has the agreed meaning. Treating absence as zero would convert the least evidenced link into the most attractive one. Treating it as some vendor default would make topology depend on undocumented local convention. Pruning preserves deterministic interpretation within the compatibility set.

Automatic Bandwidth Metric calculation adds a controlled exception, not a general fallback. If the winning definition requests automatic calculation and no explicit Bandwidth Metric exists, the router can derive one from advertised Link Bandwidth. If that underlying bandwidth is also missing, RFC 9843 requires the link to be pruned for that calculation. The receipt must therefore distinguish “explicit metric absent, derived value available” from “both metric and derivation input absent”. A single null column cannot carry that distinction.

The protocol foundations are old and deliberately separate. RFC 1195 and RFC 2328 establish IS-IS and OSPF. RFC 5305 and RFC 3630 add traffic-engineering attributes. RFC 9843 does not erase their provenance: for legacy metric types, legacy advertisements remain authoritative and a duplicate Generic Metric form is ignored.

The missing constraint input leaves the question open

The minimum-bandwidth constraint, called FAEMB, performs a different test. If a link advertises Maximum Link Bandwidth and that value is below the threshold in the winning definition, the link is pruned. If the bandwidth value is absent, the link is not excluded on this constraint. It proceeds to later pruning rules.

The maximum-delay constraint, FAEMD, is symmetrical in its evidence logic. It compares an advertised minimum unidirectional delay with the configured maximum. A value above the limit excludes the link. If the delay advertisement is absent, this constraint does not exclude it.

RFC 8570 and RFC 7471 define the delay advertisements. RFC 9479 and RFC 9492 define application-specific link-attribute carriage for IS-IS and OSPF. Field location, application scope and the L flag matter because “a delay exists somewhere in link state” is not the same as “the selected application may consume this delay”.

The missing-value rule is permissive only in a narrow logical sense. It does not certify that the link meets the threshold. It says the threshold rule lacks the premise needed to reject it. Calling that a pass would turn absence of evidence into evidence of adequacy. Calling it a prune would invent a fail-closed policy not present in the common rule. Operators that require known bandwidth or known delay must add an explicit local admission control, pre-deployment completeness gate or compatible algorithm design—and document that choice separately.

Automatic metrics are policy functions, not live load

RFC 9843 provides two ways to turn capacity into a Bandwidth Metric. The reference-bandwidth method divides a configured reference value by link bandwidth. A granularity value truncates small changes so the metric does not churn with every minor capacity movement. The threshold method maps capacity bands to assigned metric values. Both methods centralize the function in the FAD so participating routers calculate consistently.

Precedence is strict. An explicitly advertised Bandwidth Metric wins over automatic derivation for that link. A definition cannot contain both the reference method and threshold method; if it does, the definition is ignored. A zero reference bandwidth invalidates its sub-TLV. Duplicate structures and duplicate metric types have deterministic selection or rejection rules rather than “best effort” merging.

Parallel links introduce another evidence trap. In Interface Group Mode, the calculation may treat parallel Layer 3 links as a group. If every parallel link advertises an explicit Bandwidth Metric, each can be used. If only a subset does, those partial advertisements are ignored and automatic calculation is used for all of them. The rule protects consistency, but it means an apparently valid individual advertisement may intentionally have no effect. RFC 8668 and RFC 9356 supply the Layer 2 bundle-member context needed to understand why group membership and working components affect derived capacity.

Most important, the RFC draws a line between capacity and demand. Its procedures assign metrics from total link capacity; they are not intended to update the metric from actual traffic flow. They do not replace the dynamic view of a Path Computation Element described by RFC 4655, or another real-time bandwidth-management mechanism. A capacity-derived low cost cannot prove spare capacity. A path calculated for “high bandwidth” traffic cannot prove that an elephant flow will fit now.

A metric receipt must preserve the consuming rule

A useful audit record begins with the winning FAD: its algorithm number, origin, sequence or selection basis, calculation type, metric type, constraints and raw bytes or canonical hash. RFC 8919 and RFC 8920 provide IS-IS and OSPF Flexible Algorithm definition context. The normative vocabulary in RFC 2119 and RFC 8174 prevents an implementation note from being confused with a requirement.

For every candidate link, the record should then capture:

  • a presence bitmap for the selected metric, Maximum Link Bandwidth, minimum delay and application-specific container;
  • the raw value, units, advertisement origin, fragment or LSA identity and age;
  • whether the metric was explicit, automatically derived or unavailable;
  • reference bandwidth, granularity, threshold table and interface-group membership where applicable;
  • duplicate, legacy-precedence and invalid-FAD decisions;
  • the first ordered pruning rule that removed the link, or the fact that it survived all rules;
  • the resulting SPF path, separate FIB observation, and any later packet or service evidence.

This receipt makes adversarial testing straightforward. Set the Generic Metric to maximum and remove all alternatives: does the link remain? Remove only the selected metric: is it pruned? Restore automatic derivation but remove Link Bandwidth: is it pruned for lack of input? Remove bandwidth while retaining FAEMB: does the link continue to later rules without being called compliant? Advertise explicit metrics on only some members of a parallel group: are they ignored consistently? Present both automatic methods: is the FAD rejected? Repeat a metric in different fragments: which instance wins?

The test is not “did every router show green?” It is “did every participating implementation preserve the same input state and produce the same ordered decision?” A common field without common absence semantics is not interoperability.

What this report does not prove

No router, implementation, vendor default, algorithm number, threshold, capacity, delay sample, topology or maintenance event was tested. No route installation, packet traversal, congestion avoidance or SLA result was observed. The Standards Track status of RFC 9843 does not prove adoption or correct implementation. A calculated Flex-Algorithm path is not evidence that traffic used it.

The conclusion is narrower and more durable. Maximum cost is not withdrawal. Missingness is not one state. The same absence can be disqualifying when it removes the metric an algorithm needs, or non-disqualifying when a particular threshold rule lacks evidence to reject a link. Only a receipt that names the consuming rule can tell those outcomes apart.

Sources