Summary

  • RFC 10066 adds PCEP signaling for several paths inside one LSP, including weighted Segment Routing lists. Earlier SR Policy signaling carried one list per candidate path.
  • The controller must respect the lower of its own computing limit and the headend's advertised installation limit. An over-limit proposal earns a protocol error; an absent weight defaults to one.

The controller has found four ways across the network. The router at the entrance can install two. Until now, a single PCEP candidate path could not carry the whole choice in a standard way. RFC 10066 supplies that missing vocabulary, then makes the second fact—the router's capacity—part of the conversation. Four clever routes do not make four forwarding slots appear.

The IETF's October Proposed Standard adds a PATH-ATTRIB object before each explicit or recorded path. Each path receives an ID; an optional weight describes its intended share of flows. A missing weight means one. A zero-weight segment list can stay in the instructions while traffic drains from it. If every list has zero weight, the candidate path is invalid. This is control-plane intent, not a traffic measurement. A 3-to-1 weight ratio describes a planned distribution of flows, not proof that exactly three quarters of bytes reached one route.

The first gate is capability negotiation. Both PCEP peers advertise MULTIPATH-CAP when opening their session. The path-computation element (PCE) declares how many forward paths it can compute; the path-computation client (PCC), usually the headend, declares how many it can install. An individual LSP may carry an override after session support is negotiated. The PCE must stay under the lower effective number. Zero means unlimited, a brave default for anyone who also reads the security section. The RFC recommends a nonzero operator limit because a compromised or errant controller could otherwise multiply state at the headend.

The refusal has teeth. A headend given more forward paths than it advertised must return PCErr type 19, value 36. A PATH-ATTRIB object sent without successful multipath negotiation triggers a different error, type 10, value 45. Yet a controller receiving an operational state report with more paths than it can itself compute must not reject that report on capacity grounds. Planned paths and reported reality have different jobs. That distinction prevents the controller's own limit from erasing what the router says is already installed.

The standard also exposes the price of the richer object. More paths mean larger PCEP messages and more per-LSP state. Different lists can have different MTUs, delays and available bandwidth. Weight changes can redistribute flows, disturb congestion control and force path-MTU discovery again. RFC 10066 calls for operators to see negotiated limits, path IDs, weights, opposite-direction associations and new error codes. A multipath dashboard that shows only one green LSP would hide the actual operating decision.

For a network owner, the procurement question is plain: show the advertised installation cap, the resulting path set and the error when the controller asks for too much. Then show that a weight change does not create avoidable churn. RFC 10066 standardizes the messages. It supplies no deployment count, measured throughput gain or proof that any particular platform implements them. The first useful field evidence will be a controller and headend exchanging this state under load, with the per-path record visible to the operator.

Sources