Summary

  • An individual Internet-Draft dated 28 October 2026 proposes monitoring path conditions, combining them into a quality score, and changing the relative weights of Segment Lists within one active SR Policy Candidate Path. It leaves the quality definition and calculation function configurable.
  • RFC 9256 maps a Segment List weight to its fraction of steered flows and says weighted load-balancing accuracy depends on the platform. A higher score can cause a forwarding change; the score alone cannot certify byte share or application improvement.

One path is sick. Who writes the diagnosis?

The draft's example gives an active Candidate Path three equally weighted Segment Lists. One route degrades. Static weights keep sending it one-third of the traffic in the authors' illustration, even while the other two routes look healthier. The proposed fix is to watch the paths continuously and change their relative weights. That sounds like a router finally listening to its own instruments. It also hands a traffic-steering decision to whoever defines the instrument panel.

The draft names delay, loss and utilization as possible inputs. A monitor on a middle or end node measures them; reports flow toward a controller or the policy head-end; a Candidate Path Quality Agent, or CPQA, aggregates the reports, computes a score and uses a function F to calculate new weights. The head-end applies those weights. Four verbs—measure, aggregate, calculate, apply—turn observations into packets on a different path. The document describes the chain, but does not fix a universal formula for mixing the metrics. It says the definition of quality is configurable. That is a real architectural choice, not a detail to be left under a nice-looking gauge.

Take the obvious disagreement. A path can offer low delay and little spare capacity; another can have room for bulk traffic and worse tail latency. A score tuned for a short inference request may rank them differently from a score tuned for a long transfer. The draft itself adds an AI-training and inference traffic-mix motivation in revision 01: large collective-communication flows care about sustained throughput, while small inference and control packets are sensitive to latency. These are the authors' motivating traffic classes, not measured results from a named network. The conflict survives the example.

A single quality number can conceal the application whose experience it was chosen to protect.

RFC 9256 makes the arithmetic less flattering

The established SR Policy architecture in RFC 9256 gives the denominator. When several Segment Lists belong to the active Candidate Path, the head-end uses weighted ECMP; a list with weight w receives a fraction w / sum(weights) of the steered flows. Its accuracy depends on the platform implementation. The weight is a direction to the forwarding system, not a meter reading from the application. Three equal weights give an equal intended share of flows in the model. They do not establish equal bytes, equal completion times, equal capacity or an observed one-third of traffic volume.

That distinction cuts both ways. The draft's three-list illustration makes the cost of static weights vivid, yet its “one-third” is a constructed steering example. Under a dynamic score, an improved path can get a larger weight and still carry fewer bytes than expected if its assigned flows are small. A congested path can receive fewer flows and still be dominated by one elephant flow. The exact flow-to-byte relationship depends on traffic mix and the platform's hashing. An operator who says “we increased the good path's weight” has reported an action. The next sentence needs an observation from forwarding and applications.

The draft proposes a limited control surface: adjust the Segment Lists of the active Candidate Path without changing that path's priority or the list composition. A separate mode would identify congested flows and redirect selected flows toward a less-congested list. These are not synonyms. Relative weight adjustment changes the distribution rule for flows. Targeted redirection chooses particular flows. The second mode may relieve an identified hot spot more quickly, but it also needs a clear rule for which flows are named and when to stop moving them. The current framework describes both modes; it does not report that either has improved a production network.

A controller may own the score; a head-end may own it instead

The document provides two operating arrangements. In centralized mode, the Controller acts as CPQA. It subscribes to reports, aggregates them, computes new weights and sends a tuple to the Head through a southbound interface such as PCEP. In distributed mode, the Head acts as CPQA, receives reports directly and changes its own forwarding table. The word “such as” matters: this framework does not define a new PCEP message or request IANA numbers. Its IANA section says no action is requested now and future protocol extensions may need code points.

Those two arrangements put the same judgment in different hands. A central controller can compare paths from a wider view and coordinate a common scoring rule. It can also apply a bad rule across many head-ends at once. A head-end can decide with local state and act without waiting for a remote computation. It can also disagree with another head-end about what “good” means. The draft explicitly leaves the quality definition configurable, so the useful audit record begins with that configuration: which metrics, from which monitors, over what interval, aggregated how, and mapped by which F to the tuple actually installed.

Authentication protects the channel that carries this choice, but it does not make the choice sound. The draft says messages among monitors, CPQA and enforcer MUST be authenticated; TLS or TCP-AO SHOULD be used. Reports can reveal internal network state, so it says encryption SHOULD be considered where privacy matters. It calls for resilience against false-report flooding, recommending rate limits and source validation. A forged report could drag traffic toward or away from a list. An authentic report from a badly placed monitor can produce a bad score just as efficiently. Origin and usefulness are separate properties of the data.

The proposal says dampening should prevent rapid weight oscillation after transient changes. It does not give one universal threshold or algorithm in this framework. That omission matters because a loop fast enough to react to a spike can also chase its own traffic: move flows, change utilization, rescore, and move again. A slower loop can leave a degraded path busy. Either setting is a local operating decision. The draft gives it a place in the design; it does not demonstrate the safe setting for every path or workload.

Revision 01 should be read accurately. The July revision 00 already contained the monitor-report-calculate-apply scheme. The October version adds a concrete AI-computing motivation and another author. Datatracker identifies it as an individual Internet-Draft, not a working-group standard. A newer revision date is evidence that the document changed; it is not evidence that a controller ran the loop or that a network got faster.

The official packet contains the proposed framework and the established SR Policy architecture. It contains no named test pairing inputs, F configuration, weights, head-end forwarding state and application outcomes. Such a record would show whether one implementation's claimed quality improvement survived the trip from scoring dial to actual flows. Until that record exists, the most honest headline is also the most useful one: the draft knows where the weight is applied; the operator still has to say who defined “better.”

Sources