Summary

  • RFC 9933 makes SR-Algorithm values visible in PCEP paths and constraints. For values 128–255, the PCE still has to resolve a winning Flexible Algorithm Definition, its metric, its constraints, participating nodes and topology attributes. The wire-visible number is therefore not a durable fingerprint of the policy that produced a route.
  • Operators need a policy-resolution receipt rather than a larger routing packet: bind each consequential computation to the winning FAD, its advertiser and scope, the metric dictionary, the ordered pruning rules, the topology snapshot and every relaxed constraint. That preserves reviewability without publishing a sensitive network map.

Imagine two path reports captured six weeks apart. Both show SR-Algorithm 130. Both came from the same PCE. Both passed capability negotiation, travelled over authenticated transport and produced syntactically valid segment lists. A dashboard paints them the same colour because the algorithm field is identical.

Yet the first path was calculated to avoid a shared-risk group and minimize delay. Before the second calculation, a higher-priority Flexible Algorithm Definition appeared. It retained the number 130, changed the metric to an operator-defined cost, added a reverse-direction exclusion and caused one router to stop participating because it did not support the winning definition. The number did not move. The policy did.

This is not a protocol failure. It is a records problem created by successful abstraction. A compact identifier allows a distributed system to invoke a complicated policy without carrying the policy every time. That is precisely why the identifier is operationally useful. It is also why an auditor cannot treat the identifier as the decision itself.

RFC 9933, “Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP),” provides a clean case study. It extends PCEP so peers can signal the algorithm associated with Segment Identifiers, request an SR-Algorithm constraint and exchange new path metrics. The standard is explicit about capability checks, errors, computation rules and operator visibility. But for Flexible Algorithms it relies on policy state learned elsewhere.

The governance question begins where the packet capture ends: which definition did this number resolve to at the moment a route was computed, and who was accountable for changing it?

What RFC 9933 actually puts on the wire

RFC 9933 is an IETF Standards Track document published in July 2026. It updates the PCEP extensions for Segment Routing over MPLS and IPv6. Its new Algorithm field can travel with SR-ERO and SR-RRO subobjects, and its SR-Algorithm TLV can sit inside the LSPA object as a path-computation constraint.

Those additions solve real interoperability problems. A PCE can no longer assume that every SID implies the default shortest-path algorithm. A PCC can ask for a particular SR-Algorithm. Reports can preserve the algorithm associated with a segment. The document also adds metric types for minimum delay, bandwidth and user-defined metrics.

The standard does not permit careless use. Both peers must advertise support before the extensions are used. An attempt to use the feature without the negotiated capability produces an invalid-operation error. A malformed object or an unknown SID also has defined failure behaviour. If a PCE cannot find a path under the requested combination of constraints, it must return an empty route or NO-PATH rather than quietly manufacture a looser answer.

These are strong protocol properties. They establish that peers understood the feature and that the response obeyed the processing contract. They do not establish that the policy attached to an algorithm number was unchanged.

For values 0 and 1, the surrounding semantics are registered: shortest path first and strict shortest path first. Values 2–127 remain a standards-controlled space. Values 128–255 are different. They are Flexible Algorithms. Their numbers point to definitions built and advertised by operators.

The distinction is easy to miss in a log line. “SR-Algorithm: 130” looks complete. For a Flexible Algorithm it is closer to a database key than to a policy document.

The winning FAD is the operative policy

RFC 9350 defines a Flexible Algorithm Definition, or FAD, as a calculation type, a metric type and a set of constraints. A configured number from 128 to 255 is associated with that bundle. Routers within the same advertisement scope must agree on a definition so that forwarding remains consistent and loop-free.

Agreement is produced by a deterministic election. Participating routers first prefer the FAD advertisement with the numerically greatest priority. If the highest priority is tied, they choose the advertisement from the router with the greatest IS-IS System-ID or OSPF Router ID. RFC 9350 calls the result the winning FAD.

That election means the operative policy is not fully named by the number. It is the number plus the current advertisements plus the election rules. A new high-priority advertisement can change the winner without renumbering the algorithm. A tie can be resolved by an originator identity that may be invisible in a high-level path record. An advertising router does not even have to participate in the algorithm for its definition to be considered by receivers.

RFC 9350 handles the distributed-computing problem carefully. If a node cannot support a calculation type, metric, constraint, flag or sub-TLV in the chosen definition, it must stop participating and remove the associated forwarding state. A definition change may trigger network-wide recomputation and reconvergence. These safeguards make the new state coherent; they do not preserve the institutional history of why the new state was authorized.

This is the first important audit boundary. A later operator may retrieve algorithm 130 and see a valid current FAD. That does not reveal which FAD won for yesterday’s computation, which competing advertisement lost, whether the change window was approved, or whether the change was meant to be temporary.

One number can legitimately mean different things in different areas

There is a second boundary: scope. RFC 9350 makes the FAD scope an area. It explicitly says a particular Flex-Algorithm need not have the same definition in all areas. The same number can optimize for delay in one area and for bandwidth in another.

That flexibility is not ambiguity inside the protocol. Each area has a defined advertisement set and a deterministic winner. It is ambiguity in an underspecified record. A report that says only “algorithm 130” has discarded the scope required to interpret the value.

The problem resembles a currency amount with no currency, or a statute number with no jurisdiction. The digits can be accurate and still fail to identify the rule. A cross-domain controller, incident reviewer or capacity planner needs to know the area, level and policy namespace in which the value was resolved.

RFC 9933 recognizes that multi-domain variation is difficult. It places the use of different SR-Algorithm constraints, or different winning FAD metrics and constraints, across parts of a single end-to-end computation outside its scope. That boundary should make an operator more cautious about global dashboards that collapse several scopes into one label.

The right response is not to forbid local variation. Localized policy is often the point of Flexible Algorithms. The response is to carry enough provenance outside the packet so that a local meaning is not mistaken for a universal one.

The request does not contain the complete policy

For Flexible Algorithm values, RFC 9933 says the PCE computes from its Traffic Engineering Database. That database is expected to contain FADs, node participation and application-specific link attributes learned through IGP extensions or mechanisms such as BGP-LS. The route is therefore a function of both the request and a changing evidence environment.

The document is especially clear about the optimization metric. The PCE must use the metric specified by the FAD. If the PCC includes an optimization metric in the PCEP request, the PCE must ignore it. The PCE applies constraints in the FAD as well as direct constraints in the request, subject to PCEP processing rules. The PCC must not copy the FAD’s own constraints into the request, because doing so can produce undesirable behaviour.

That is good protocol factoring. It avoids duplicating distributed definition state inside every request. It also means that replaying a saved request later is not necessarily replaying the same decision. If the winning FAD, topology attributes, participating nodes or rule set changed, the same request may correctly yield another route.

A path report can therefore be complete as a PCEP artefact and incomplete as an audit artefact. It shows what was requested and returned. It may not show the policy environment that made the response correct.

Metrics carry local institutions inside numbers

RFC 9843 deepens this point. It extends Flexible Algorithms with bandwidth and delay constraints, automatic bandwidth-metric calculation and generic metrics. It also reserves metric types 128–255 for meanings assigned by an operator for local use.

That local space is powerful. An operator may model fiscal cost, jitter, energy exposure or another property that standard registries do not yet name. But a path cost using “metric 130” is only intelligible if the local dictionary for metric 130 is available. RFC 9843 warns that, when a user-defined metric crosses areas or levels, all domains should assign the same meaning to the value.

Even a standardized bandwidth metric has policy inputs. A link may advertise an explicit value, which overrides automatic derivation. If it does not, the winning FAD can supply a reference bandwidth or thresholds from which the metric is calculated. Change the reference, and path costs can change across the domain without changing the SR-Algorithm number.

This is not merely a configuration-detail problem. Choosing whether “cost” means delay, capacity, money or an internally weighted blend allocates scarce infrastructure. It decides which traffic crosses which facilities and which failure margins are consumed. The metric dictionary is part of the institution’s operating policy.

A useful record must therefore include more than the metric-type byte. For a user-defined metric it needs the semantic version, units, normalization rules, owner and effective date. For an automatically derived metric it needs the derivation method and parameters. Otherwise a later reviewer can recompute the arithmetic and still misunderstand what the arithmetic represented.

The evaluator changes as well as the inputs

Path computation does not only select a metric and minimize it. It prunes links that violate the definition. RFC 9917 created the IANA “IGP Flex-Algorithm Path Computation Rules” registry as an ordered set of pruning rules.

The IANA registry now lists checks for excluded administrative groups, shared-risk groups, include-any and include-all groups, missing metrics, bandwidth and delay thresholds, and reverse-direction administrative groups. Its registration policy is Expert Review, and there is no fixed upper bound on the number of rules.

An ordered registry is a versioned evaluator. Two implementations can hold the same FAD and topology but differ if one applies an older rule set or lacks support for a new constraint. RFC 9933 addresses unsupported combinations by requiring computation failure. That protects conformance, but a bare NO-PATH response may still leave an investigator asking which rule and which evidence eliminated the last candidate.

This is a familiar weakness in automated governance. Institutions preserve inputs and outputs, then forget that the evaluator is also state. A credit model has a version. A sanctions screen has a list date. A route calculator has a pruning sequence and an implementation build. Reproducibility requires all three: inputs, policy and evaluator.

Objective function, algorithm and metric are not synonyms

PCEP already has another important abstraction. RFC 5541 defines objective functions used to choose the best candidate path or set of paths. A PCC can mark an objective function as required or desired. When it is merely desired, a PCE may choose a different function according to local capability and policy.

RFC 9933 says directly that SR-Algorithm does not replace the objective function. Nor is an algorithm number the same thing as a metric type. The layers interact, but they answer different questions:

  • the SR-Algorithm constrains the computation family and, for a Flexible Algorithm, selects a FAD namespace;
  • the FAD supplies a calculation type, a metric type and constraints;
  • the objective function specifies what the PCE should optimize among valid candidates;
  • the topology database supplies the current evidence;
  • processing rules determine which optional objects may be relaxed or ignored.

An operations screen that displays only one of these layers may encourage false certainty. “Algorithm 130 succeeded” does not reveal whether a desired objective was replaced, a direct constraint was ignored, or a new FAD metric displaced the metric an engineer thought they requested.

RFC 9753 improves accountability for optional processing in stateful PCEP by defining how peers indicate that objects may be ignored and how an ignored object is reported. That disposition belongs in the evidence record. A constraint that was present but optional is institutionally different from one that was mandatory, unsupported or never sent.

Secure transport cannot version the policy

RFC 9933 recommends protecting PCEP with TLS and cites the relevant PCEPS guidance. RFC 9916 updates that secure-transport profile for current TLS behaviour. Authentication and confidentiality matter: an attacker must not be allowed to rewrite a path request or impersonate a controller.

But a perfectly authenticated message can invoke a newly changed policy. TLS can prove which peer sent bytes over a protected session. It cannot prove which change board approved FAD priority 200, why a cost dictionary was revised, or whether an emergency definition should have expired last Tuesday.

The same distinction appears repeatedly in technical governance. Integrity protects the record one has. It does not guarantee that the record contains the evidence one will later need.

A policy-resolution receipt

The missing object should not be another mandatory field in every PCEP packet. Routing protocols have strict performance, interoperability and disclosure constraints. A governance record can live alongside the operational exchange and refer to sensitive inputs by digest.

Call it a policy-resolution receipt. For each consequential computation or policy epoch, it would bind:

  1. the request identifier, PCE and PCC identities, time and topology scope;
  2. the SR-Algorithm value and the place it appeared—as a SID attribute, a path constraint or both;
  3. the normalized winning FAD and its cryptographic digest;
  4. the winning advertiser, priority, tie-break inputs and advertisement scope;
  5. the metric dictionary or derivation parameters effective at that time;
  6. the objective function, including whether it was mandatory, desired or substituted;
  7. direct PCC constraints and the disposition of every optional or ignored object;
  8. the ordered pruning-rule registry snapshot and implementation version;
  9. a digest of the topology database, node-participation set and relevant capability exclusions;
  10. the result—ERO, empty ERO or NO-PATH—and a structured reason;
  11. the change ticket, approving role, activation window, rollback trigger and next review date.

The receipt need not publish the topology, commercial link costs or security-sensitive exclusions. A general view can expose identifiers, hashes, versions, reason classes and custody. A privileged auditor can resolve those commitments against protected material. The goal is not radical transparency. It is controlled inspectability.

This design also separates two kinds of change. A topology event may alter a route under an unchanged policy; a policy event may alter a route under similar topology. If the receipt versions both, incident review can tell which kind occurred instead of inferring policy from the path alone.

Sources