PCE Working Group C. Lin Internet Draft New H3C Technologies Intended status: Standards Track Expires: January 19, 2024 July 19, 2025 Extensions to the Path Computation Element Communication Protocol (PCEP) for SR Policy Performance Metric draft-lin-pce-sr-policy-performance-metric-00 Abstract This document describes a way to report the performance metrics for Traffic Engineering (TE) Policy by the Path Computation Element Communication Protocol(PCEP). Status of this Memo 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 January 19, 2024. Copyright Notice Copyright (c) 2025 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. Lin, et al. Expires January 19, 2024 [Page 1] Internet-Draft PCE Extension for SR Policy Performance Metric July 2025 Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Extensions to METRIC Object....................................3 3. Security Considerations........................................4 4. IANA Considerations............................................4 5. References.....................................................5 5.1. Normative References......................................5 5.2. Informative References....................................6 Authors' Addresses................................................6 1. Introduction The Path Computation Element (PCE) is a network component, application, or node that is capable of computing a network path or route based on a network graph and applying computational constraints. The PCE Communication Protocol (PCEP) enables communication between a PCE and Path Computation Clients (PCCs), facilitating the computation of optimal paths for traffic flows. [RFC8664] introduces the concept of Segment Routing Policy (SR Policy), which is a set of candidate paths that can be used to steer traffic through a network. Each candidate path is represented by a list of segments, and the path can be dynamically adjusted based on network conditions and requirements. [I-D.ietf-spring-stamp-srpm] describes the procedures for Performance Measurement in SR networks, using STAMP as defined in [RFC8762]. The described procedure is used for SR paths [RFC8402](including SR Policies [RFC9256]). The METRIC object is defined in Section 7.8 of [RFC5440]. The METRIC object can be carried in the PCReq message as a constraint for the metric to be calculated, or it can be included in the PCRep message with the calculated path metric value. In some network scenarios, the PCE needs to obtain the performance information of TE Policies, which can be used for better service placement and more efficient utilization of network resources. Currently, there is no definition for the real-time test metric values of SR paths. When the real-time metric values of SR paths are measured through [I-D.ietf-spring- stamp-srpm], they need to be reported to the PCE via the PCRep message. This document describes a way to report the performance metrics for Traffic Engineering (TE) Policy by the Path Computation Element Communication Protocol(PCEP). Lin, et al. Expires January 19, 2024 [Page 2] Internet-Draft PCE Extension for SR Policy Performance Metric July 2025 It defines new flag and new metric types for the METRIC object required to support Reporting the performance metric of SR Policy. 1.1. Requirements Language 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. 2. Extensions to METRIC Object The performance metric of SR Policy may be measured at the headend, for example, by using STAMP for SR Policy [I-D.ietf-spring-stamp- srpm]. But the measurement methods are out of the scope of this document. The METRIC object is defined in Section 7.8 of [RFC5440]. This document expands the Flag field to indicate that the METRIC object contains an actual measurement metric. Add the definition of the R bit in the Flags of the METRIC Object TLV: Codespace of the Flag field (Metric Object) Bit Description Reference TBD Real Measuring metric This document R (Real Measuring Metric - 1 bit): When set in a PCRep message, this indicates that the PCC MUST provide the actual measured path metric value in the PCRep message for the corresponding metric. For the one-way measurement of SR Policy performance metrics, the following directions are used to report: * Set R=1 in the Flags field and and Type=12 of the metric object to in dicate the measured Delay metric of the path. * Set R=1 in the Flags field and Type=13 of the metric object to indicate the measured Path Delay Variation metric of the path. * Set R=1 in the Flags field and Type=14 of the metric object to indicate the measured Loss metric of the path. Lin, et al. Expires January 19, 2024 [Page 3] Internet-Draft PCE Extension for SR Policy Performance Metric July 2025 * Set R=1 in the Flags field and Type=22 of the metric object to indicate the measured Path Min Delay Metric of the path. Define a new maximum one-way delay type: T=TBD1: Path Max Delay. Set R=1 in the Flags field and Type=Path Max Delay of the metric object to indicate the measured Path Max Delay Metric of the path. Five new metric types are defined to report the two-way performance metrics of SR Policy, as follows: T=TBD2: Round-trip Delay: This metric Type advertises the average round-trip delay for SR Path. T=TBD3: Round-trip Min Delay: This metric Type advertises the minimum round-trip delay for SR Path. T=TBD4: Round-trip Max Delay: This metric Type advertises the maximum round-trip delay for SR Path. T=TBD5: Round-trip Variation: This metric Type advertises the average round-trip delay variation for SR Path. T=TBD6: Round-trip Loss: This metric Type advertises the the round- trip loss for SR Path. When reporting the bidirectional delay, minimum delay, maximum delay, variation, and loss in a PCRep message, the R bit for the new position needs to be set. 3. Security Considerations This document does not introduce any new security consideration. 4. IANA Considerations Codespace of the Flag field (Metric Object) Bit Description Reference TBD Real Measuring metric This document Lin, et al. Expires January 19, 2024 [Page 4] Internet-Draft PCE Extension for SR Policy Performance Metric July 2025 Add the definition of the R bit in the Flags of the METRIC Object TLV: R (Real Measuring Metric - 1 bit): When set in a PCRep message, this indicates that the PCC MUST provide the actual measured path metric value in the PCRep message for the corresponding metric. Codespace of the T field (Metric Object) Value Meaning Reference TBD Path Max Delay This document TBD Round-trip Delay This document TBD Round-trip Min Delay This document TBD Round-trip Max Delay This document TBD Round-trip Variation This document TBD Round-trip Loss This document 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, Lin, et al. Expires January 19, 2024 [Page 5] Internet-Draft PCE Extension for SR Policy Performance Metric July 2025 DOI 10.17487/RFC9552, December 2023, . 5.2. Informative References [I-D.ietf-spring-stamp-srpm] Gandhi, R., Filsfils, C., Voyer, D., Chen, M., and R. F.Foote, "Performance Measurement Using Simple Two-Way Active Measurement Protocol (STAMP) for Segment Routing Networks", Work in Progress, Internet- Draft, draft-ietf-spring-stamp-srpm-19, 20 June 2025, . Authors' Addresses Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Lin, et al. Expires January 19, 2024 [Page 6]