Summary

  • RFC 10066 lets a path controller describe several forwarding paths inside one PCEP LSP. Before the controller sends them, both peers advertise the multipath capacity they can handle. The smaller effective limit wins.
  • A client can reject an oversized computed path set, report a larger operational set without being treated as erroneous, or keep a path installed at zero weight while traffic drains elsewhere. Those are three different decisions, with three different receipts.

The map has more roads than the box

A controller can draw routes all afternoon. The device expected to install them has a finite appetite. RFC 10066, published in October 2026, gives that mismatch a wire format: multiple forwarding paths can live under one Path Computation Element Communication Protocol (PCEP) label-switched path. For Segment Routing Policy, one candidate path can finally carry several segment lists over PCEP. The older SR Policy architecture allowed that shape, while RFC 9862 left the actual multiple-list signaling outside its scope. The architecture described the destination before the protocol could carry the full itinerary.

Multipath lets the controller describe diversity and weight. It does not give the controller unlimited room in the receiving device. RFC 10066 requires the PCE and its path computation client (PCC) to negotiate support and a maximum number of multipaths. When computing a path, the PCE must respect the smaller of the two effective limits. If it sends more than the PCC advertised, the PCC returns a defined PCErr: error type 19, value 36, unsupported multipath capability. A controller's ambition is a proposal; the receiving node's stated installation limit is a constraint.

That limit may be set for the session or overridden for an individual LSP. If multipath support was never negotiated, a PATH-ATTRIB object arriving later is an error. These rules make the boundary visible in a protocol exchange. Operators still have to decide whether the advertised number matches hardware, software, policy and available resources. A number in an OPEN message is evidence of declared capability, not a measurement of installed forwarding entries.

The reverse exchange has an interesting asymmetry. A PCC may send a PCRpt reporting more paths than the PCE's own computation limit. RFC 10066 tells the PCE not to mark that report as an error: the client is describing operational state, not asking the controller to compute extra roads. This is a small but valuable piece of restraint. A system that treats every state report as a command would reject information precisely when it falls outside its preferred picture. The controller can have a smaller pencil than the device has a history.

Weight can move traffic without erasing a path

The new optional MULTIPATH-WEIGHT TLV gives each path an unsigned 32-bit weight. When the weight is absent, the default is one. The share assigned to a path is defined by its weight relative to the sum of the path weights, in the weighted equal-cost model. Zero is a sharper tool: for an SR Policy segment list, it declares that path invalid for traffic and can drain it while retaining the forwarding instructions. If every path is at zero, the candidate path itself is invalid under the SR Policy rules. A control plane can keep the map on the wall while telling traffic to use another door.

This distinction matters during maintenance. Removing a path, setting its weight to zero, reducing its relative weight and letting a failed path vanish from operational state are different events. They imply different rollback prospects. An operator who records only “multipath enabled” loses the decision that moved load. An operator who records the path IDs, old and new weights, installation status and observed traffic can explain why a quiet path was quiet. The RFC defines signaling; a measured traffic split would require real forwarding telemetry.

RFC 10066 also leaves per-path metric encoding for future work. The METRIC object can still describe the LSP as a whole. It cannot, by this new standard alone, tell an operator that every segment list has the same latency or loss. RFC 10067 is a separate companion for associating a forward and reverse Segment Routing LSP so endpoints can know the opposite-direction path. It is another reminder that “one service” can contain several paths, directions and kinds of evidence. A controller screen that collapses all of them into a green line has edited out the interesting part.

There is a governance story inside the packet format. The standard describes how peers express a proposal, a capacity claim, a refusal, a weight and an operational report. It assigns neither a public mandate to the controller nor business priority to any traffic class. A network operator chooses how much path diversity to request, what a weight change is allowed to move, which device limit is trustworthy, and what evidence is required before announcing that redundancy works. Heng Lu's Note 73 asks who can authorize a binding decision.

Here, the answer lives with the operator who owns the forwarding consequences, not with whichever PCEP speaker has the tidiest diagram.