Summary

  • RFC 7471, a March 2015 Proposed Standard co-authored by Alia Atlas, specifies OSPF TE extensions that can distribute unidirectional delay, delay variation, loss and bandwidth-performance information. The document says its mechanisms only distribute network-performance information; the methods of measurement and the actions taken after distribution are outside its scope.
  • That means a reported TE value is evidence about a defined information exchange, not a receipt for a live route or a service. RFC 7823 says a path-computation function may use such information and a computed path may be signalled or used by an ingress router. Neither conditional step proves that any named network took it.

The number has an address, a direction and a boundary

Traffic engineering encourages a seductive compression. A network exposes a delay, loss or bandwidth value; a path system consumes it; an observer then speaks as though the number describes the path itself. RFC 7471 is more careful. It describes extensions to OSPF TE that distribute information associated with a link. Its unidirectional delay, for example, is from the advertising node to the directly connected OSPF neighbour. It is not a declaration about a complete journey through a network, much less an application transaction or a customer's experience.

The standard makes the representation concrete. It provides sub-TLVs for unidirectional link delay, minimum and maximum delay, delay variation, unidirectional loss, residual bandwidth, available bandwidth and utilised bandwidth. Delay and variation are expressed in microseconds; loss as a percentage; bandwidth in bytes per second. Those units make a value portable enough to be interpreted by an implementation that understands the extension. They do not cause unlike measurement conditions, network policies or objectives to become one common truth.

That is why the scope sentence is central rather than incidental. The RFC's mechanisms only distribute network-performance information. It leaves the way an operator measures a property outside scope. It also leaves outside scope the decision an ingress router, a path computation element, a controller or an operator makes once the attribute is available. The document creates a shared vocabulary and encoding surface. It does not silently take custody of the systems that observe, optimise or operate the network.

Exchange state is not operating state

The update semantics reinforce this distinction. Apart from residual bandwidth, the performance values are rolling averages over a configurable interval. RFC 7471 defines threshold and filter behaviour, an A bit for a threshold excursion and a reuse threshold, and a throttle for the delay between announcements. The default announcement interval is 120 seconds and may not be lower than the measurement interval. Each extension may be enabled or disabled. Dynamic values may be superseded by manually configured or static values when dynamic measurement is unavailable or when a migration calls for it.

These are not defects. They are a recognition that a flooded routing representation needs stability and that operators keep local choices. A value can be recent enough for one decision but stale for another; a static value can be deliberately used where a live measurement is unavailable; a threshold can avoid excessive churn while making short-lived variation invisible to a downstream reader. None of those states is an error merely because it is not a continuously sampled reality.

But they make a specific inference invalid: seeing an attribute does not show what was measured at this moment, nor does it show that the attribute was decisive. A value may have been averaged, filtered, held, overridden or simply not used by the relevant decision maker. An honest operational account names which of those meanings applies instead of calling every advertised number “the path metric.”

Several later decisions remain local

RFC 7823 places the next boundary in plain view. It describes the use of OSPF and IS-IS TE metric extensions for performance-based path computation. A path-computation function may use the information for a criterion such as latency, jitter or loss. A path it computes may be signalled with RSVP-TE, or used by an ingress router with segment routing. It also notes that multiparameter optimisation can be computationally complex and may call for heuristics.

The repeated “may” is architecture, not evasiveness. A path engine has to choose a request, constraints, objective, topology view and feasibility rule. It may receive a value but reject the candidate path. It may compute a candidate but decide not to install it. Signalling may fail, an LSP may not be established, or forwarding state may differ from the intended plan. A path can be installed and still fail to carry a particular flow. Traffic can flow and still not demonstrate the delay, loss or application behaviour an external reader cares about.

Each step has a different owner and a different receipt. The measurement system can show method, sampling window and source. The OSPF control plane can show the advertised value and its age. The path computation system can show the input set, constraints, candidate and reason for selection or rejection. The signalling and forwarding plane can show installed state. Independent probes, counters or service telemetry can support a claim about observed delivery. A TE attribute belongs at the second of those stages. It cannot honestly impersonate the others.

A minimum common surface prevents a larger fiction

This is where the design aligns with Heng Lu’s distinction between a minimum shared specification and later local decisions. An interoperable system needs a small stable surface: a field, unit, encoding, direction, update rule and scope that participants can recognise. It should not pretend to standardise every local measurement apparatus or every optimisation decision simply because the same value crosses a protocol boundary.

Localized future decision is not a gap to conceal. A transit operator, an enterprise, a controller designer and a path-computation service may have different aims and different evidence obligations. One may favour latency, another loss, another spare capacity, another policy isolation. RFC 7471 lets them exchange a representation without forcing a universal formula for the decision. Voluntary adoption has the same implication: the existence of an RFC and an advertised sub-TLV does not establish that a particular implementation, domain or service uses it.

The useful question is therefore not “what path does this metric promise?” It is “what information has this system actually distributed, who controlled its construction, and what later receipt would be needed to substantiate the path claim?” That question is more demanding, but it preserves both the standard’s utility and the operator's responsibility.

Attribute a contribution without inventing operational authority

RFC 7471 lists Stefano Giacalone, David Ward, John Drake, Alia Atlas and Stefano Previdi as authors. RFC 7823 also lists Atlas among its authors. Her IETF Datatracker profile is a public record for identifying the person and her documented RFC context. That is enough to ground a person-centred reading of the work.

It is not evidence that Atlas solely authored either document, selects paths in a current network, controls an operator's telemetry, or guarantees any service outcome. The IETF text defines a standards surface. Operators, implementation teams, path engines and network-control systems retain their own authority and their own evidence. The contribution is valuable precisely because it names a portable information boundary rather than claiming to make every later layer automatic.

Evidence limits

The cited RFCs do not identify a current deployment, a current topology, a current TE value or a particular route. They do not prove that a path computation ran, selected an output, sent RSVP-TE signalling, applied a segment-routing instruction, installed forwarding state or carried a flow. They also do not prove end-to-end reachability, an application result or customer experience.

The proposed receipt chain is an operational inference from those boundaries, not a new RFC requirement. It is a way to keep a precise distributed representation useful without allowing its presence to erase the local decisions and observations that a real path claim still requires.

Sources