Summary

  • RFC 10041 lets OSPF use LSLinkInfinity (0xffff) to exclude a link from the associated SPF calculation, but only after every router represented in the area's link-state database advertises the Unreachable Link capability.
  • A legacy router joining the area can revoke that condition. During capability-LSA propagation, routers may interpret the same metric differently and form transient forwarding loops.
  • Daniel Kade proposes an area-semantic activation receipt that freezes the live router roster, capability evidence, affected links, convergence interval, recomputation and rollback conditions without pretending configuration inventory proves forwarding.

One number, two forwarding worlds

Imagine two neighboring routers looking at the same link-state advertisement. Router A sees metric 65,535 and removes the link from its shortest-path calculation. Router B sees the same value and keeps the link as an exceptionally expensive but reachable last resort. Both behaviors can be correct under the rules they implement. Together, they can send packets back to each other.

RFC 10041 changes the established OSPF interpretation of the maximum link metric. The older behavior in RFC 2328 treated 0xffff as reachable. The new Unreachable Link capability gives that value a harder meaning: do not consider the link in the associated SPF calculation.

The change solves a real modeling problem. An OSPF link may need to remain visible for traffic engineering, or for a Flexible Algorithm under RFC 9350, without entering the base hop-by-hop topology. Advertising the link is useful; allowing the default SPF to select it is not.

But the same bits cannot safely mean two things inside one area. RFC 10041 therefore binds the new semantics to a collective condition.

Unanimity is observed, not configured

Supporting routers advertise a functional-capability bit in an area-scoped Router Information LSA. A router must not interpret LSLinkInfinity as unreachable unless every router represented by a Router-LSA in the area's LSDB advertises that capability.

This is stronger than “the upgrade plan is complete.” It is also different from “the controller says every device supports the feature.” The protocol condition lives in the link-state database each router actually sees.

When the count of non-supporting routers falls to zero, the area can enter the new semantic state. When it rises from zero because a legacy router joins or a capability advertisement disappears, routers must return to the compatible interpretation. Both transitions require route recalculation.

The governing unit is therefore not a box or a software image. It is a time-bound area-wide proposition: at this observation point and epoch, every router participating in the area signaled the same interpretation.

Convergence creates a dangerous interval

Area-scoped LSAs do not arrive everywhere simultaneously. RFC 10041 explicitly notes the case of a legacy router joining an area that previously had complete support. Routers gradually discover the new non-supporting member. During propagation, some may still treat 0xffff as unreachable while others treat it as reachable.

That disagreement can produce a transient loop. One router forwards toward a neighbor because it retains the maximum-cost link; the neighbor excludes that link and sends traffic back along a different calculation.

The hazard is not simply “old router present.” It is the interval during which the area's semantic state has changed but observation has not converged. A deployment record that contains only pre-change capability checks cannot explain what the network believed during that interval.

Operators need to observe at least three moments: the intended transition, the first LSDB evidence that changes the unanimity condition, and the point at which representative routers have recalculated under a common interpretation. A configuration push is not any of those moments by itself.

0xfffe preserves a different promise

OSPF already used the maximum metric for several softer signals. Stub Router Advertisement discourages transit through a router. LDP-IGP synchronization raises cost while label distribution catches up. Graceful link shutdown discourages a link before planned removal. These cases want “use only as a last resort,” not “this edge is absent.”

RFC 10041 defines MaxReachableLinkMetric (0xfffe) to preserve that meaning once 0xffff can mean unreachable. It updates RFCs 5443, 6987, 8379 and 8770 accordingly.

The one-step numerical difference carries a major governance boundary. 0xfffe retains emergency reachability. 0xffff, under unanimous capability, removes the link from the associated SPF. Dashboards and change tickets that flatten both into “high metric” discard the operator's actual intent.

Auto-costing introduces another edge case. A formula based on inverse bandwidth could naturally produce the maximum for a very slow but valid link. Implementations supporting RFC 10041 must cap that computed value at 0xfffe, preventing arithmetic from accidentally turning “costly” into “unreachable.”

Reachability has several meanings

An advertised unreachable link is not necessarily physically down. It may remain visible for a traffic-engineering database or be usable by a Flex-Algorithm whose metric choice does not apply LSLinkInfinity in the same way. Conversely, a link kept at 0xfffe may be operational but intentionally discouraged for transit.

These distinctions matter because different teams own them. Physical operations knows whether light, interface and adjacency exist. IGP policy controls the base topology. TE systems compute constrained paths. Flex-Algorithm policy defines a separate calculation. Forwarding hardware installs the result.

RFC 10041 changes one calculation rule. It does not prove that a TE tunnel was selected, that a Flex-Algorithm path was programmed, that packets flowed, or that the physical circuit failed. A good record must name the precise verb: advertised, interpreted, excluded, calculated, installed or observed.

Management access can change the area's vocabulary

RFC 10041 includes YANG modules that augment the OSPF management model in RFC 9129. The capability and per-interface unreachable advertisement are configurable. The default is not to advertise the capability.

Those writable nodes are sensitive. Unauthorized changes can prevent routers from adopting the unreachable interpretation or cause a link to be advertised as unreachable. Read access can also reveal topology-control details useful to an attacker. The RFC points to secure, mutually authenticated NETCONF or RESTCONF transport and to NACM under RFC 8341 for bounded authorization.

Authorization and stability are separate. A compromised router can rapidly change its capability advertisement and force repeated SPF calculations. RFC 10041 recommends the SPF back-off algorithm in RFC 8405. Back-off protects the calculation engine from churn; access control restricts who may cause the change. Neither proves that the whole area has converged.

An area-semantic activation receipt

I propose an area-semantic activation receipt for RFC 10041 rollouts. This is Daniel Kade's governance proposal, not an additional IETF requirement.

The receipt starts with area identity and scope. It freezes the router roster as observed through Router-LSAs, not merely the asset inventory. For each router it stores a bounded reference to the Router Information LSA, capability state, sequence or freshness evidence and observation point.

The next section records the transition. It identifies the change owner, intended activation or revocation, previous and new count of non-supporting routers, first decisive LSA, propagation window and routers selected as convergence canaries. A later join or withdrawal opens a new epoch; it does not silently amend the old receipt.

The link section separates intent. For each affected edge it records 0xffff as excluded under the active semantics, 0xfffe as reachable but discouraged, any TE or Flex-Algorithm use, and the auto-cost cap. It does not label a link physically down without separate evidence.

The outcome section records route recalculation and bounded route or next-hop comparisons from representative routers. Loop canaries look for reciprocal next hops, TTL-expiry signals or abrupt traffic loss during the semantic transition. Forwarding proof remains distinct from LSDB agreement.

Finally, the receipt states rollback conditions: appearance of any non-supporting router, loss or staleness of capability evidence, inconsistent LSDB views, repeated capability flapping, or observed loops. It preserves who may disable advertisement, how 0xffff links are handled during fallback, and when the area can be reassessed.

No full LSDB dump, device credentials or sensitive topology map needs to be public. Hashes, counts, bounded identifiers, time windows and controlled link references can make the transition auditable without publishing an attack plan.

The semantic state is temporary by design

The IANA registry gives the capability bit a durable identity, and the IANA-maintained YANG module lets implementations track future registry changes. Yet the area's actual permission to use the new meaning is deliberately revocable.

That revocability is a strength. It keeps an upgraded router from imposing new semantics on a legacy neighbor. It also creates an operational duty: the system must notice when unanimity ends.

Monitoring should therefore track roster changes, capability-LSA freshness, the number of non-supporting routers as seen from multiple points, recomputation events, flapping rates, links at each special metric and auto-cost outputs. Evidence expires with a router join, area merge, software downgrade, capability withdrawal, LSA aging event or policy change.

RFC 10041's deeper lesson is that protocol meaning can be shared state. The bits in one advertisement do not carry enough authority on their own. Only the area, observed in agreement, can turn the largest OSPF metric from an expensive road into no road at all.

Sources

  1. Lu Heng — Data Sovereignty: Technical vs Practical Realities
  2. Lu Heng — Why BTW Media Exists
  3. Lu Heng — Running-Code Primacy
  4. RFC 10041 — Advertising Unreachable Links in OSPF
  5. RFC 2328 — OSPF Version 2
  6. RFC 5340 — OSPF for IPv6
  7. RFC 5443 — LDP IGP Synchronization
  8. RFC 6987 — OSPF Stub Router Advertisement
  9. RFC 7770 — OSPF Router Information Advertisement
  10. RFC 8341 — Network Configuration Access Control Model
  11. RFC 8379 — OSPF Graceful Link Shutdown
  12. RFC 8405 — SPF Back-off Delay Algorithm
  13. RFC 8770 — OSPFv3 Stub Router Advertisement
  14. RFC 9129 — YANG Data Model for OSPF
  15. RFC 9350 — IGP Flexible Algorithm
  16. IANA — OSPF Parameters