| Internet-Draft | PCEP Per-Path Metric | October 2026 |
| Sidor & Ali | Expires 3 May 2027 | [Page] |
The Path Computation Element Communication Protocol (PCEP) extensions for signaling multipath information allow multiple forwarding paths to be associated with a single PCEP Label Switched Path (LSP); for Segment Routing (SR) Policy, these paths are the Segment Lists of a Candidate Path. However, the METRIC object remains encoded at the LSP level, and per-path encoding of the METRIC object is explicitly left out of scope.¶
This document extends PCEP to signal per-path (for SR Policy, per Segment List) metric information by reusing the existing METRIC object within the multipath constructs, and defines the associated capability negotiation.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The METRIC object, defined in [RFC5440], carries metric information for a path, such as the computed value of a metric or a bound on it. The PCEP extensions for signaling multipath information [RFC10066] allow multiple forwarding paths to be associated with a single PCEP Label Switched Path (LSP), using the PATH-ATTRIB object to carry per-path information and to separate the Explicit Route Objects (EROs) or Record Route Objects (RROs) of the individual paths. As noted in Section 3.2 of [RFC10066], however, the METRIC object continues to be used at the LSP level to describe properties of the overall LSP, and mechanisms for encoding per-path metrics are explicitly left outside the scope of that document. As a result, when an LSP contains multiple paths with different computed metric values, there is no standardized way to report the metric of each individual path.¶
This document fills that gap. It defines how the existing METRIC object is reused to carry per-path metric information within the multipath constructs of [RFC10066], and it defines the capability negotiation required to signal this information in a backward compatible manner. Support for [RFC10066] is a prerequisite for the extensions defined in this document.¶
These extensions are generic and, like [RFC10066], applicable to any path setup type that supports multipath. Their primary application is Segment Routing (SR) Policy [RFC9256], where an LSP is an SR Candidate Path and each path is a Segment List.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the following terms defined in [RFC5440]:¶
This document also uses the term "PCEP speaker" to denote a PCC or PCE that implements PCEP, consistent with its usage in [RFC5440] and [RFC10066].¶
This document uses the following PCEP message abbreviations:¶
This document uses the terms "path", "Segment List", "LSP", and "Candidate Path" as defined in [RFC10066]. The generic term "path" is used throughout so that the mechanisms remain applicable to any path setup type that supports multipath, consistent with [RFC10066]. In the context of SR Policy, which is the primary application, a path corresponds to a Segment List and an LSP corresponds to a Candidate Path.¶
In PCEP, an SR Policy Candidate Path is represented as specified in [RFC9862], and may be a Segment Routing over MPLS [RFC8664] or a Segment Routing over IPv6 (SRv6) [RFC9603] path.¶
The term "LSP-level METRIC" refers to a METRIC object that applies to the overall LSP (Candidate Path), as described in Section 3.2 of [RFC10066]. The term "per-path METRIC" refers to a METRIC object that applies to a single path (Segment List), as defined in this document.¶
An SR Policy Candidate Path that contains multiple Segment Lists load-balances traffic across those Segment Lists, as described in Section 2.11 of [RFC9256]. Because each Segment List traverses a different path through the network, the Segment Lists of a Candidate Path can have significantly different metric values, for example a different IGP metric, TE metric, or path delay.¶
Because the METRIC object is carried only at the LSP (Candidate Path) level, there is currently no standardized way to report the metric of each individual Segment List. Collapsing the per-Segment-List values into a single LSP-level value is lossy, and the appropriate aggregation depends on the metric type (see Section 5.3). Reporting the value of each Segment List explicitly gives the receiver the per-Segment-List information it would otherwise lack.¶
This document defines a single, capability-gated mechanism for signaling per-path metrics that applies consistently across the stateful (PCRpt, PCUpd, and PCInitiate) and stateless (PCRep) PCEP messages that carry multipath information, building on the multipath constructs of [RFC10066]. The following subsections describe the main use cases.¶
The primary use case is local re-evaluation of the aggregate Candidate Path metric at the PCC. A PCC may use the Candidate Path metric in local decisions, for example as an input to BGP path selection. When one or more Segment Lists are locally invalidated (for example, by a Bidirectional Forwarding Detection (BFD) [RFC5880] session or a performance-measurement liveness check that runs per Segment List, as used by Circuit-Style SR Policy [I-D.ietf-spring-cs-sr-policy]), the aggregate metric changes, but the PCC cannot reflect this until the PCE recomputes and updates the Candidate Path. If each Segment List carries its metric, the PCC can re-evaluate the aggregate metric locally and immediately, without recomputing the paths. A PCC often cannot compute per Segment List metrics on its own, for example for inter-domain paths or where Binding SIDs of non-local policies are used.¶
Candidate Path (LSP): PCC (H) -> Endpoint (E)
with three Segment Lists (paths)
+===== SL1 (IGP 10) =====+
| |
PCC (H) ----+===== SL2 (IGP 20) =====+---- Endpoint (E)
| |
+===== SL3 (IGP 30) =====+ X invalidated
(BFD / PM)
LSP-level (aggregate) IGP metric = max over valid SLs:
before: max(10, 20, 30) = 30
after : max(10, 20) = 20 (re-evaluated at H)
A further use case is advertising the per-Segment-List metric northbound. When a PCE computes the Segment Lists and passes them to the PCC, the PCC may advertise the policy state using BGP Link-State (BGP-LS) [RFC9857]. The SR Policy advertisement in [RFC9857] carries the metric per Segment List and not per Candidate Path; its per Segment List metric sub-TLV expects the value to be supplied by the computation entity, which may be a controller when the path is delegated. If the PCE provides only an aggregate Candidate Path metric, the PCC has no way to populate the per Segment List metric. The resulting information flow is illustrated below.¶
+------------------------------------------------+
| PCE: computes CP = { SL1(m1), SL2(m2) } |
+------------------------------------------------+
|
| PCEP: per-SL METRIC (this document)
v
+------------------------------------------------+
| PCC |
+------------------------------------------------+
|
+--> re-evaluates the CP aggregate metric locally
| when an SL is invalidated (BFD / PM)
+--> uses the CP metric locally (e.g. BGP path
| selection)
+--> advertises the per-SL metric via BGP-LS
[RFC9857]
The mechanism is not specific to any one metric type. Performance metric types such as path delay, path delay variation, and packet loss, defined for the METRIC object in [RFC8233], can be reported per Segment List using the mechanism in this document. Similarly, the Path MTU metric type defined in [I-D.ietf-pce-pcep-pmtu] is carried in the METRIC object and would be reported per Segment List; that document notes support for Segment Routing Path MTU at the Segment List level as future work.¶
This document defines a new flag in the MULTIPATH-CAP TLV (Section 4.1.1 of [RFC10066]). As with the other flags in that TLV, it MAY be present both in the OPEN object (as a session default) and in the LSP object (to specify a per-LSP value), following the rules defined there.¶
The M flag indicates that the advertising speaker is willing to receive per-path METRIC objects. The per-LSP granularity allows a PCC to enable per-path METRIC objects for specific LSPs rather than for all LSPs of the session: the M flag in the LSP object is set by the PCC and expresses the PCC's capability to receive per-path METRIC objects for that LSP, overriding the session default advertised in the OPEN object. As required by Section 4.1.1 of [RFC10066], the MULTIPATH-CAP TLV may appear in the LSP object only if it was present in the OPEN objects of both peers. The per-LSP value governs the stateful messages for that LSP; the stateless PCRep message is governed solely by the session default in the OPEN object.¶
Because the M flag denotes support for reception, a PCEP speaker MUST NOT include a per-path METRIC object in a message unless the peer that receives the message has advertised the M flag (for the session via its OPEN object or, for a specific LSP, via the LSP object). Consequently, a PCE includes per-path METRIC objects toward a PCC only when that PCC has advertised the M flag (per session or, for stateful messages, per LSP), and a PCC includes per-path METRIC objects toward a PCE only when that PCE has advertised the M flag for the session. A PCC's per-LSP M flag conveys only the PCC's own ability to receive per-path METRIC objects for that LSP; it does not by itself permit the PCC to send them. A per-path METRIC object received without the corresponding capability is treated as an error (Section 5.4).¶
Per-path METRIC objects are populated according to the role of the PCEP speaker. A PCE provides computed values when it returns or updates paths, in PCRep, PCUpd, and PCInitiate messages. A PCC reports the values of its paths in PCRpt messages. In all cases, a per-path METRIC reports a computed value with the B (Bound) flag clear, as specified in Section 5.1. This document does not extend the PCReq message: a per-path METRIC conveys a computed value, which a PCE returns in a reply or in a stateful message and a PCC reports in a PCRpt, whereas the PCReq message carries a path computation request.¶
A per-path METRIC is a METRIC object, as defined in Section 7.8 of [RFC5440], that is associated with a single path (Segment List) rather than with the overall LSP. It reports the computed value of the indicated metric type for that path. The B (Bound) flag MUST be clear, since a per-path METRIC reports a computed value and not a bound. The C (Computed Metric) flag is set as specified in [RFC5440]. The P (Processing-Rule) and I (Ignore) flags in the common object header of the per-path METRIC object follow [RFC5440] and are not modified by this document.¶
More than one per-path METRIC MAY be associated with the same path, to report values of different metric types. The metric types that can be reported are those defined for the METRIC object, for example those defined in [RFC5440], [RFC5541], and [RFC8664].¶
This document extends the RBNF defined in Section 5 of [RFC10066] to carry a per-path metric list, where <metric-list> is a sequence of one or more METRIC objects, as defined in [RFC5440]. A METRIC object carried in a per-path position is a per-path METRIC object. The position of the per-path metric list differs between the stateful messages (Section 5.2.1) and the stateless PCRep message (Section 5.2.2).¶
The <intended-path> and <actual-path> constructs of Section 5 of [RFC10066] are updated as follows:¶
<intended-path> ::= <ERO> |
<PATH-ATTRIB>[<metric-list>]<ERO>
[<intended-path-multipath>]
<intended-path-multipath> ::=
<PATH-ATTRIB>[<metric-list>]<ERO>
[<intended-path-multipath>]
<actual-path> ::= <RRO> |
<PATH-ATTRIB>[<metric-list>]<RRO>
[<actual-path-multipath>]
<actual-path-multipath> ::=
<PATH-ATTRIB>[<metric-list>]<RRO>
[<actual-path-multipath>]
A per-path <metric-list> is enclosed between a PATH-ATTRIB object and the ERO or RRO that immediately follows it, and applies to the path (Segment List) described by that PATH-ATTRIB object; placing it immediately before the route object ensures that the route object always delimits the per-path metrics from any LSP-level attribute list that precedes or follows the path (see Section 5.3). An intended per-path metric list is carried in the <intended-path> construct (delimited by its ERO), and an actual per-path metric list is carried in the <actual-path> construct (delimited by its RRO); the intended and actual metric lists for the same path are correlated by the PATH-ATTRIB Path ID, as defined in [RFC10066]. The LSP-level attribute list carried elsewhere in the message, as defined in [RFC8231] and [RFC8281], continues to apply to the overall LSP (Candidate Path).¶
A per-path <metric-list> MAY be associated with a reverse path (a path whose PATH-ATTRIB object has the R flag set, as defined in [RFC10066]). In that case the per-path values apply to the reverse path, which may have different metric values than its forward counterpart.¶
In the PCRep message, the per-path encoding reuses the existing structure: a METRIC object within the attribute-list already associated with each path in the updated <path> element of Section 5 of [RFC10066] is a per-path METRIC object. The position of the per-path <metric-list> relative to its route object therefore differs between message types: in the stateful <intended-path> and <actual-path> constructs it precedes the ERO or RRO (so that the route object delimits it from any following LSP-level attribute list), whereas in the PCRep <path> element it follows the ERO, within that path's own attribute list as defined in Section 5 of [RFC10066]. This difference reflects the base encodings: the PCRep <path> already provides a per-path attribute list, whereas the stateful constructs do not. In both cases a route object separates the per-path metrics from any LSP-level metric list, so the encoding remains unambiguous.¶
The PCRep <path> construct of Section 5 of [RFC10066], reproduced below, carries the per-path METRIC object within each path's <attribute-list>:¶
<path> ::= <ERO><attribute-list> |
<PATH-ATTRIB><ERO><attribute-list>
For a given metric type, per-path METRIC objects are provided on an all-or-nothing basis across the forward paths of an LSP (that is, the paths whose PATH-ATTRIB object has the R flag clear): if a per-path METRIC of a metric type is included for any forward path, a per-path METRIC of that metric type MUST be included for every forward path of that LSP; a PCEP speaker that receives an LSP that violates this rule MUST treat it as an error as described in Section 5.4. Different metric types are handled independently. This ensures that a receiver can derive the corresponding LSP-level aggregate over the forward paths (Section 5.3). A per-path METRIC MAY also be reported for a reverse path (a path whose PATH-ATTRIB object has the R flag set); such values are informational, are not subject to the all-or-nothing rule above, and are not included in the LSP-level aggregate. An LSP whose paths carry no per-path METRIC objects is handled as in [RFC10066], which preserves backward compatibility with implementations that do not support the extensions defined in this document. An example that combines per-path and LSP-level METRIC objects is provided in Appendix A.¶
A per-path METRIC object applies only to the path identified by its PATH-ATTRIB object, whereas an LSP-level METRIC object describes the overall LSP (Candidate Path) as specified in Section 3.2 of [RFC10066].¶
An LSP-level METRIC object and per-path METRIC objects for the same LSP MAY both be present in the same message. The two are unambiguous: each per-path <metric-list> is enclosed between a PATH-ATTRIB object and its ERO or RRO (Section 5.2), whereas an LSP-level METRIC object is carried in the LSP-level attribute list (the <actual-attribute-list> or <intended-attribute-list> defined in [RFC8231], or the attribute list defined in [RFC8281]). The ERO or RRO of each path separates the per-path metric list from any LSP-level metric list, so no run of METRIC objects spans the two. An LSP-level METRIC object MAY carry a metric bound (B flag set) or a computed value (B flag clear); a per-path METRIC object always carries a computed value with the B flag clear (Section 5.1).¶
When per-path METRIC objects are reported and a receiver requires an LSP-level aggregate, it derives the aggregate from the per-path values of the LSP's forward paths (those whose PATH-ATTRIB object has the R flag clear). This document does not mandate a specific aggregation rule, because the appropriate aggregation depends on the metric type:¶
Because per-path METRIC objects of a given metric type are provided for every forward path of an LSP (Section 5.2), a receiver can always derive the corresponding LSP-level value from the per-path values. The reverse is not possible: the per-path values cannot be recovered from a single LSP-level value. Providing the per-path METRIC objects is therefore preferred. A sender MAY include both the per-path METRIC objects and a computed (B flag clear) LSP-level METRIC of the same metric type, but the LSP-level computed value is then redundant; a sender SHOULD rely on the per-path values and MAY omit it. If a receiver is given both a per-path and a computed LSP-level METRIC of the same metric type, the per-path values take precedence. An LSP-level METRIC that carries a bound (B flag set) conveys a request constraint rather than a computed value and is unaffected by this guidance.¶
If a PCEP speaker receives a per-path METRIC object (that is, a METRIC object in the per-path position defined in Section 5.2) but the M flag capability was not negotiated as described in Section 4, it MUST treat this as an error and MUST send a PCErr message with Error-Type 19 ("Invalid Operation") and Error-value "Per-path METRIC capability not negotiated" (Section 6.2).¶
If a PCEP speaker receives a per-path METRIC object with the B (Bound) flag set, it MUST treat this as an error and MUST send a PCErr message with Error-Type 10 ("Reception of an invalid object") and Error-value "Per-path METRIC with Bound flag set" (Section 6.2).¶
If a PCEP speaker receives an LSP in which a per-path METRIC of a given metric type is present for some but not all paths (see Section 5.2), it MUST treat this as an error and MUST send a PCErr message with Error-Type 10 ("Reception of an invalid object") and Error-value "Per-path METRIC missing for one or more paths" (Section 6.2).¶
All IANA actions in this section pertain to the "Path Computation Element Protocol (PCEP) Numbers" registry group, available at https://www.iana.org/assignments/pcep/.¶
IANA is requested to make the following assignment in the "Flags in MULTIPATH-CAP TLV" registry defined in [RFC10066]:¶
| Bit | Description | Reference |
|---|---|---|
| TBD1 | M flag: per-path METRIC support | This document |
IANA maintains the "PCEP-ERROR Object Error Types and Values" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. See https://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object¶
IANA is requested to make the following assignments:¶
| Error-Type | Meaning | Error-value | Reference |
|---|---|---|---|
| 19 | Invalid Operation | TBD2: Per-path METRIC capability not negotiated | This document |
| 10 | Reception of an invalid object | TBD3: Per-path METRIC with Bound flag set | This document |
| TBD4: Per-path METRIC missing for one or more paths | This document |
The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC9256], and [RFC10066] are applicable to this document.¶
This document reuses the existing METRIC object and does not introduce new PCEP messages. It increases the amount of per-LSP state and the size of PCEP messages, since metric information may be reported for every path of an LSP. A misbehaving or compromised PCEP speaker could attempt to amplify state or message size by reporting a large number of per-path METRIC objects; the "Number of Multipaths" field of the MULTIPATH-CAP TLV, as described in [RFC10066], bounds the number of paths per LSP and thereby limits this exposure.¶
Per-path METRIC objects expose finer-grained information than the LSP-level METRIC: they reveal the metric of each individual Segment List rather than only an aggregate. For performance-related metric types such as path delay, delay variation, and packet loss ([RFC8233]), this per-path information can be sensitive, as it may disclose details of the internal topology and performance of the network. The considerations in Section 8 of [RFC8233] regarding the sensitivity of service-aware information apply equally to the per-path values defined in this document.¶
It is RECOMMENDED that these PCEP extensions be activated only on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC9325].¶
All manageability requirements and considerations listed in [RFC5440], [RFC8231], and [RFC10066] apply to the extensions defined in this document. In addition, the following considerations apply.¶
A PCEP speaker implementation SHOULD allow an operator to enable or disable the per-path METRIC capability advertised in the MULTIPATH-CAP TLV (the M flag defined in Section 4), both at the session level and, where applicable, per LSP.¶
It is expected that a future version of the PCEP YANG module [RFC9826] will be extended to cover the capability and per-path METRIC objects defined in this document.¶
This document does not introduce any new liveness detection or monitoring requirements in addition to those already defined in [RFC5440] and [RFC8231].¶
An implementation SHOULD allow an operator to view the per-path METRIC objects reported for each path within an LSP, as well as the per-path capability negotiated for a session and for individual LSPs.¶
The mechanisms in this document increase the size of PCEP messages and the amount of per-LSP state, since metric information may be reported for every path of an LSP. The "Number of Multipaths" field of the MULTIPATH-CAP TLV, as described in [RFC10066], bounds the number of paths per LSP and can be used to limit this impact.¶
The extensions defined in this document do not impose any new requirements on other protocols.¶
Figure 5 illustrates how per-path and LSP-level METRIC objects are combined in a single message. The example builds on the SR Policy Candidate Path encoding of Appendix A.1 of [RFC10066], in which a Candidate Path (LSP) contains two Segment Lists (paths). Each path carries a per-path IGP METRIC (B flag clear) enclosed between its PATH-ATTRIB object and its ERO, and the overall LSP carries an LSP-level IGP METRIC in the intended attribute list that follows the last ERO.¶
<state-report> =
<LSP PLSP-ID=100>
<PATH-ATTRIB Path ID=1>
<METRIC T=IGP, B=0, C=1, metric-value=10> (per-path, SID-List1)
<ERO SID-List1>
<PATH-ATTRIB Path ID=2>
<METRIC T=IGP, B=0, C=1, metric-value=20> (per-path, SID-List2)
<ERO SID-List2>
<METRIC T=IGP, B=0, C=1, metric-value=20> (LSP-level)
The first two METRIC objects are per-path: the one with metric-value 10 applies to SID-List1 (Path ID 1) and the one with metric-value 20 applies to SID-List2 (Path ID 2), because each is enclosed between a PATH-ATTRIB object and its ERO. The final METRIC object follows the last ERO and is part of the LSP-level intended attribute list; it describes the overall LSP, with metric-value 20 being the maximum (worst-case) IGP metric over the two paths (Section 5.3). The ERO of Path ID 2 separates the per-path METRIC of SID-List2 from the LSP-level METRIC, so the two are unambiguous. An LSP-level metric bound (a METRIC object with the B flag set) would occupy the same LSP-level position.¶
TBD.¶