Summary

  • RFC 9862 represents an SR Policy as a PCEP Association and each Candidate Path as an LSP. The Candidate Path is the signaling unit, but some signaled choices govern the policy containing all of those paths.
  • Drop-Upon-Invalid is carried in an INVALIDATION TLV on a Candidate Path. If any Candidate Path enables it, the feature is enabled for the whole SR Policy; it takes effect only after every Candidate Path becomes invalid.
  • A policy-wide drop receipt should join capability negotiation, complete Candidate Path membership, configuration and operational flags, the all-invalid transition, the selected drop carrier and observed packet outcome. This is Daniel Kade's editorial proposal, not an RFC field or IETF requirement.

A red flag beside one path appears local. It sits on one row, arrives in one LSP object and can be attached to one identifier. A management system can therefore store it as a property of that path. RFC 9862 makes the storage location technically accurate and the simple interpretation wrong.

The INVALIDATION TLV carries the configuration for Drop-Upon-Invalid at Candidate Path level. Yet the feature is not enabled for that path alone. If any Candidate Path carries the configuration D flag, Drop-Upon-Invalid is enabled for the entire SR Policy. The consequence waits until a second condition becomes true: every Candidate Path in the policy is invalid. At that point the policy enters drop state, selects the highest-preference Candidate Path among those with the feature enabled, keeps attracting the relevant traffic and discards it at the headend instead of allowing an ordinary fallback.

One object carried the instruction. A set crossed the threshold. A policy changed behavior. Packets paid the consequence. Those are four different scopes, and none can be safely substituted for another.

The protocol speaks in paths while the decision lives in a set

Segment Routing Policy already distinguishes a policy from its ways of realizing that policy. A policy can contain one or more Candidate Paths. RFC 9862 extends PCEP by representing the policy as a new SR Policy Association, or SRPA, and representing each Candidate Path as an LSP inside that association. This is an intelligible mapping: PCEP's unit of signaling is the LSP, so the Candidate Path becomes the thing a speaker can advertise, update and report.

The mapping has an evidentiary consequence. Information about the SR Policy is carried at Candidate Path level even when its meaning cannot be evaluated from one path alone. The SRPA joins the members, but a record of one LSP does not reconstruct the set unless the management plane preserves association identity and membership over time.

That is why the SRPA identifiers matter. The policy is identified by color and endpoint, while the Candidate Path has its own originator and discriminator. A Candidate Path can belong to at most one SRPA, its identifier remains stable within the PCEP session, and duplicates inside a policy are invalid. Those constraints make correlation possible. They do not perform the correlation for an operator after paths have changed, sessions have restarted or telemetry has sampled only the object that emitted an alert.

RFC 9862 also requires capability exchange. Both peers advertise support for the SR Policy Association before using it. A speaker that advertises the capability must include the association for every SR Policy LSP it originates. The separate SRPOLICY-CAPABILITY TLV exposes support for computation priority, explicit-null behavior, invalidation and stateless operation. A received object without the required negotiated capability is an error, not evidence that the peer silently accepted the feature.

Capability evidence therefore answers a narrow question: was the vocabulary available to both ends of this PCEP session? It does not prove which Candidate Paths were valid, whether all members had been observed, or whether traffic was later dropped.

One letter D describes two different facts

The INVALIDATION TLV contains two flag fields. In the configuration field, D means that the Candidate Path has Drop-Upon-Invalid enabled. In the operational field, D means that the LSP is actively dropping traffic because the behavior has been activated. The same letter is convenient protocol notation, but the two states must never be collapsed in an operational record.

Configuration is intent. It says what should happen if the policy reaches a particular failure condition. The operational flag is a report of the state selected after that condition. Neither, by itself, proves the data-plane outcome. Packet counters, forwarding behavior and the duration of the state remain separate observations.

Direction matters as well. From PCE to PCC, the configuration tells the client whether to enable or disable the behavior. From PCC to PCE, the report returns both the current setting and whether the LSP is in drop state. If a system stores the latest value without the message direction, speaker identity and timestamp, it can confuse an instruction with an acknowledgement or an intended setting with an observed result.

The normal behavior supplies the counterfactual. When an LSP becomes down or invalid, it usually stops attracting traffic, allowing the traffic to move by another LSP or the IGP. Drop-Upon-Invalid does the opposite on purpose: the headend continues to attract the traffic and drops it. That can be a rational safety decision when falling through to an unintended route would be worse than refusing the traffic. It can also create a severe outage if the setting is stale, mis-scoped or misunderstood. The standard supplies the mechanism, not a universal risk preference.

The last invalid path is the decisive event

An SR Policy is invalid when all of its Candidate Paths are invalid. This is a set predicate, not a property that any one path can truthfully announce about itself. The first invalid path may reduce resilience. The second may change the preferred alternative. The last valid path becoming invalid crosses the policy boundary.

Only then does the policy inspect whether any Candidate Path has Drop-Upon-Invalid enabled. If so, it enters drop state and activates the highest-preference enabled Candidate Path. RFC 9862 says only one Candidate Path needs to be reported to the PCE with the operational Dropping flag. That is efficient signaling. It is not a complete causal record.

Suppose a policy has three Candidate Paths. The lowest-preference path carries configuration D because an earlier operator wanted a hard failure for a particular service. The two higher-preference paths do not carry it. Months later, topology changes make the first two paths invalid. Nothing drops yet because one path remains valid. When that last path fails, the policy-wide feature is enabled because of the old flag on the low-preference member. The active drop carrier is then chosen from the paths that have D enabled.

A monitor that sees only the final operational D can show where the policy is reporting the drop, but not which instruction made the policy eligible, when it was approved, or why it remained present.

Preference also has to be named correctly. Candidate Path preference selects the best path; higher values win, and RFC 9256 gives it a default of 100. RFC 9862's computation priority controls the order of recomputation after a topology change; lower values have higher priority, and its conditional default is 128. These numbers govern different queues in opposite directions. A telemetry schema that calls both “priority” can produce a plausible but inverted explanation of the decision.

Absence and local override are decisions, not blank cells

RFC 9862 contains several deliberate defaults. If the computation-priority capability is enabled and the per-LSP TLV is absent, the default is 128. If an explicit-null-label policy is absent, local configuration decides. That explicit-null behavior applies to SR-MPLS and is ignored for SRv6; unrecognized values are ignored; and local operator configuration may override what was signaled.

These rules expose a recurring governance error: treating a missing field as “no policy.” Sometimes absence invokes a default. Sometimes it delegates the choice to local configuration. Sometimes the field is inapplicable to the data plane. Sometimes an advertised value is superseded by an operator's explicit choice. A database null cannot represent all four.

The same discipline applies to invalidation. An operator reviewing a drop needs the effective decision, its source and its precedence. Was the D flag received from the PCE, preserved from local configuration, changed after association, or removed but not yet reflected in a sampled report? Which software version and PCEP session interpreted it? Did the full membership set used for the all-invalid test match the set the operator believed existed?

RFC 9862 helps by requiring operators to be able to view the advertised SR Policy and Candidate Path identifiers, and by recommending visibility into peer capabilities and LSPs associated with a policy. That visibility is necessary. A durable explanation still requires joining the observations into one transition.

A receipt for the scope expansion

The policy-wide drop receipt proposed here begins with the policy identity: color, endpoint and SRPA identity as observed on each peer. It records the negotiated association and invalidation capabilities for the relevant PCEP session. It then freezes the Candidate Path membership set used for the decision, including each path's originator, discriminator, preference, configuration D value and validity state.

Next comes the transition. Record the timestamp and observation source for every path that became invalid, identify the moment the last valid member crossed the threshold, and preserve which Candidate Paths had Drop-Upon-Invalid enabled at that moment. Record the highest-preference enabled Candidate Path selected as the drop carrier, the operational D report, the PCE and PCC message directions and any discrepancy between intended and reported state.

Finally, bind the control-plane event to outcome evidence. Did traffic continue to be steered into the policy? Which counters show discards at the headend? When did the first and last drops occur? Was traffic restored because a Candidate Path became valid, the configuration changed, the policy membership changed or the whole policy was withdrawn? Identify the owner who approved the setting, the exception or service class it protected, its review date and the rollback path.

This receipt is not a proposal to export topology to a central authority. The association and path data can expose sensitive policy information, and RFC 9862 inherits the recommendation for authenticated and encrypted PCEP sessions between PCE and PCC under the same administrative authority, using TLS. Evidence should remain scoped, access-controlled and no more detailed than the operational decision requires.

Nor is the receipt an RFC extension. It is an editorial method for preventing a management system from confusing the place where a bit is encoded with the place where power is exercised.

Running code has to close the loop at packet level

The doctrine in Heng Lu's work is useful here because it refuses to let institutional language outrun operational fact. PCEP may express intent, an SRPA may define membership, and an INVALIDATION TLV may carry a setting. None of those observations alone is the packet outcome. The running system decides whether the headend kept attracting traffic, whether it discarded that traffic, how long the state lasted and what restored service.

That does not make the protocol irrelevant. The protocol gives the operator a precise vocabulary and a predictable state machine. It also defines a boundary that governance must respect: the IETF standardizes interoperable behavior, while the operator chooses whether controlled dropping is preferable to fallback for a particular service. A monitoring system should expose that choice, not silently make it and not pretend the RFC endorsed the business consequence.

The durable lesson is narrower than “central control is dangerous” and more useful than “collect more logs.” When a control is carried by one member but changes the behavior of a set, evidence must expand to the same scope as the consequence. Otherwise every local record can be accurate while the resulting explanation is false.

Sources