Summary

  • In the SPRING working group's worked example, an SR Policy candidate path carries 200 Mbps over two equal-weight Segment Lists, each assumed to handle 100 Mbps. Lose one list and RFC 9256's recommended validity test can still call that candidate path valid. The surviving list has only half the capacity assumed by the example.
  • A proposed pair of thresholds would let an operator require a minimum count and cumulative weight of valid lists before keeping the candidate path active. The values need an owner and a capacity premise; the draft does not install a protection by itself.

A green light on a narrow bridge

Put 200 Mbps of traffic on two roads built for 100 Mbps each. Give the roads equal weight, and the arithmetic is pleasingly dull: half the flows on each. Now close one road. The SPRING working-group draft's example says the remaining Segment List cannot carry the full load. Yet CP1, the candidate path containing both lists, can remain the active path under the recommended validity rule in RFC 9256. The status lamp stays green while the capacity premise collapses.

That is a sharper problem than the familiar complaint that a dashboard uses the wrong colour. The headend can make a decision that is perfectly consistent with a protocol's path-validity rule and poorly matched to the traffic the operator assigned to that path. The word valid tells the truth about one question: at least one usable Segment List remains. It says nothing on its own about whether the remainder can carry the booked demand. A control room that treats the first answer as the second has converted a narrow technical predicate into a broad service promise.

The draft's POL1 has two candidate paths, CP1 and CP2. CP1 is valid, has the higher preference and is active. Its SL1 and SL2 each have weight 1 and an assumed maximum capacity of 100 Mbps; flow-based hashing splits the 200 Mbps load evenly in the example. When one list becomes invalid, the other can remain valid. RFC 9256 recommends at least one valid constituent Segment List as a criterion for candidate-path usability; an explicit candidate path becomes invalid when it has no valid list. CP1 therefore need not lose its active status when its capacity halves.

CP2 is present in the example, but its capacity and what traffic it would ultimately carry are unspecified.

Count the surviving roads

The proposal gives the headend two more questions to ask. The first is a Minimum Valid Segment List Count, an 8-bit threshold. Set it to 2 in the example and CP1 fails the test as soon as either list disappears. Set it to 0 and there is no extra count requirement. The value 0xff means every list must be valid. The second is a Minimum Cumulative SL Weight, a 32-bit threshold. With weights 1 and 1, a threshold of 2 also makes CP1 invalid when one list is lost: the remaining weight is only 1. Zero removes that extra requirement; 0xffffffff demands all lists be valid. When both parameters are configured, the candidate path must satisfy both. Set both to zero and the RFC 9256 mechanism applies.

The count is easy to understand but can be blunt. Two surviving lists are not automatically worth 200 Mbps; one might be a narrow path and the other a fat one. Weight permits a more tailored threshold, but it is a relative steering value, not a capacity meter. In the worked example the authors assign equal weights because they assume equal 100 Mbps capacities. If the underlying bandwidth changes while the weights remain 1 and 1, a sum of 2 can be mathematically correct and operationally misleading. The threshold must be coupled to a maintained capacity model and the actual load it is supposed to protect.

A label on the route cannot do that accounting for the operator.

This is where the decision changes hands. The draft says a headend may receive the validity-control parameters through configuration, PCEP or BGP. It leaves those protocol extensions to another document and makes no IANA request. It does not designate a universal count or weight for every network. An operator decides what remaining capacity is tolerable for a service, sets the threshold, distributes it, and checks that the headend applies the intended value. The same policy name can conceal different risk appetite on two networks if their configured thresholds differ.

Three different failures can wear one badge

The vocabulary matters because SR Policy has layers. A Segment List may be invalid under the resolution and verification rules of RFC 9256. A candidate path may still be valid if another list survives. An SR Policy becomes invalid only when all its candidate paths are invalid. A change in path validity calls for candidate-path selection to be run again; the highest-preference valid path may then become active. The proposed threshold operates at the candidate-path level. It can force CP1 out of contention earlier. It does not, by itself, say CP2 has the spare capacity the service needs, or that a policy-wide invalid state has been reached.

That boundary separates this proposal from RFC 9256's Drop-Upon-Invalid behaviour. Drop-Upon-Invalid concerns what happens when the whole SR Policy is invalid. The draft confronts an earlier, more awkward interval: a preferred candidate path remains formally valid while its surviving Segment List is too small for the example's assigned demand. A policy can therefore look healthy before anyone reaches the dramatic all-paths-invalid case. The first mistake would be to wait for total failure before asking whether the active path can still do its job.

No production trace accompanies the draft's 200/100/100 Mbps example. A deployment record showing the configured thresholds, actual list capacities, measured load and resulting path selection would change an assessment of operational effect. The current proposal establishes a possible mismatch and a way to state an operator's tolerance explicitly. It does not show that a named network has already overloaded a surviving list.

The person who owns the number

An operator can turn the proposal into a concrete acceptance test. Record the demand assigned to CP1, the valid status of each list, the count and weight sum, the configured minimums, the source of those minimums, and the time at which CP1 changed status. If a controller supplies the values, compare the controller's intended threshold with what the headend actually received. If a link or forwarding resource changes capacity, revisit the mapping between that capacity and the list's weight. A green path status is useful only when the team can answer what it certified.

The draft authors have not asked the IETF to choose the operator's service budget. That is a strength of this narrow proposal. The shared protocol can expose a threshold; the network that sells or promises the capacity must decide the threshold's value and bear the consequence of a stale one. A controller can send a number, a headend can enforce it, and a monitoring system can display it. Accountability starts when those three views can be reconciled after a list fails.

Sources