OPSAWG Y. Liu Internet-Draft ZTE Intended status: Standards Track Z. Li Expires: 3 March 2027 Y. Liu China Mobile C. Lin New H3C Technologies G. Dong China Telecom 30 August 2026 Export of Segment Routing Path Segment Identifier (PSID) Information in IPFIX draft-ietf-opsawg-ipfix-path-segment-06 Abstract This document introduces new IPFIX Information Elements to identify the Segment Routing (SR) Path Segment Identifier (PSID) for SR-MPLS and SRv6 paths identification. 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 3 March 2027. Copyright Notice 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 Liu, et al. Expires 3 March 2027 [Page 1] Internet-Draft IPFIX for PSID August 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. SR-MPLS Path Identification . . . . . . . . . . . . . . . 3 1.2. SRv6 Path Identification . . . . . . . . . . . . . . . . 3 1.3. SR Path Segment . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PSID in IPFIX . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. SR-MPLS PSID in IPFIX . . . . . . . . . . . . . . . . . . 5 3.2. SRv6 PSID in IPFIX . . . . . . . . . . . . . . . . . . . 6 3.3. PSID Use Cases . . . . . . . . . . . . . . . . . . . . . 6 4. Operational Considerations . . . . . . . . . . . . . . . . . 7 4.1. Generic Operational Considerations . . . . . . . . . . . 7 4.1.1. PSID-to-Path Mapping Model . . . . . . . . . . . . . 7 4.1.2. PSID Under Path Changes . . . . . . . . . . . . . . . 8 4.1.3. PSID Scope and Uniqueness . . . . . . . . . . . . . . 9 4.2. Operational Considerations for psidMplsLabelStackSection . . . . . . . . . . . . . . . . 9 4.3. Operational Considerations for srhPsidIPv6 . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction When monitoring a traffic flow in an SR network, a typical use case is to answer the following questions: * How many packets are steered into a certain SR path ? * Which SR Policy or candidate path or segment list this SR path belongs to ? To answer these questions, when exporting IPFIX flow records, the SR path information needs to be included. However, there are still some shortcomings with the existing mechanisms. Liu, et al. Expires 3 March 2027 [Page 2] Internet-Draft IPFIX for PSID August 2026 1.1. SR-MPLS Path Identification In SR-MPLS [RFC8660], a segment is encoded as an MPLS label. For MPLS label stack information collection, IPFIX IE mplsLabelStackSection (elementID:316) [RFC5477] can carry a series of n octets from the MPLS label stack of a sampled packet, which can be leveraged to carry the whole or part of the MPLS label stack. And IEs from mplsTopLabelStackSection, mplsLabelStackSection2, mplsLabelStackSection3 to mplsLabelStackSection10 (elementID from 70 to 79) [RFC5102] provide mechanism to carry the individual MPLS label information in the IPFIX message. But the above IEs are not sufficient for SR-MPLS path identification: * The intermediate node and the egress node cannot use the SR label stack to determine along which SR path the packet came, because when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. * Although the headend node may have the information of the whole segment list, the size of IPFIX messages (especially the data record) would be big when a segment list contains many SIDs, making the collecting and analyzing of flow records inefficient. * In the cases that different SR (whether it is SR-MPLS or SRv6) policies use the same segment list for traffic steering, it is difficult to distinguish the traffic flow of different SR policies even with the whole SR list information of the traffic flow. 1.2. SRv6 Path Identification [RFC9487] introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6). For the SRv6 segment list, two IPFIX IPv6 SRH IEs are defined in [RFC9487], srhSegmentIPv6BasicList (elementID:496) and srhSegmentIPv6ListSection (elementID:497), both encoding the Segment List in the SRH starting from Segment List[0]. An SRv6 path could be identified by the content of a segment list in IPFIX using IE496 or IE497, but the segment list is not always the best key identifier due to the following reasons: * The size of an SRv6 SID is much bigger than an SR-MPLS SID, making the size of IPFIX message even larger when the segment list contains many SIDs. Liu, et al. Expires 3 March 2027 [Page 3] Internet-Draft IPFIX for PSID August 2026 * An SRv6 path may not be identified by the segment list carried by the SRH in reduced mode as described in Section 4.1.1 of [RFC8754] where the first SID is not present in the SRH. * When the srhSegmentIPv6BasicList or srhSegmentIPv6ListSection contains compressed-SID containers [RFC9800], additional information and processing procedures are required to decode compressed-SID containers as described in Section 6.2 of [RFC9487] to obtain the original segment list information before compression. 1.3. SR Path Segment Path Segment is a type of Segment Routing (SR) segment, and a Path Segment Identifier (PSID) is used to identify an SR path. For SR-MPLS, as specified in [RFC9545], a PSID is a single label that is assigned from the Segment Routing Local Block (SRLB) of the egress node of an SR path, and it immediately follows the last label of the SR path. PSID for SRv6 networks is defined in [I-D.ietf-spring-srv6-path-segment]. In SRH, the PSID appears in the last entry in the segment list. This document introduces new IPFIX Information Elements to identify the PSIDs for SR-MPLS and SRv6 paths identification. 2. Terminology 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 makes use of the terms defined in [RFC7011], [RFC8402], [RFC8754] and [RFC9545]. The following terms are used as defined in [RFC7011]: * IPFIX * IPFIX Information Elements * Metering Process * Template Record Liu, et al. Expires 3 March 2027 [Page 4] Internet-Draft IPFIX for PSID August 2026 * Data Record * Collector The following terms are used as defined in [RFC8402]: * Segment Routing (SR) * Segment List * SRv6 The following terms are used as defined in [RFC8754]: * SRH * Last Entry The following terms are used as defined in [RFC9545] and [I-D.ietf-spring-srv6-path-segment]: * PSID: Path Segment Identifier 3. PSID in IPFIX 3.1. SR-MPLS PSID in IPFIX A new IE "psidMplsLabelStackSection" is defined in this document to identify the SR-MPLS PSID, it carries an MPLS label that represents an SR-MPLS PSID, as well as the Exp, and S fields from the label stack entry that containing a PSID. Name: psidMplsLabelStackSection ElementID: TBD1 Description: The Label (i.e., the MPLS PSID), Exp, and S fields from the label stack entry that contains a PSID. The size of this Information Element is 3 octets. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label(PSID) | Exp |S| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Label: the MPLS PSID, 20 bits Liu, et al. Expires 3 March 2027 [Page 5] Internet-Draft IPFIX for PSID August 2026 Exp: Experimental Use, 3 bits S: Bottom of Stack, 1 bit Abstract Data Type: octetArray Data Type Semantics: default Additional Information: Specified in [RFC9545]. Reference: This document. 3.2. SRv6 PSID in IPFIX A new IE "srhPsidIPv6" is defined in this document to identify the PSID in the SRH, it carries a 128-bit value that represents an SRv6 PSID. Name: srhPsidIPv6 ElementID: TBD2 Description: The 128-bit value that represents an SRv6 PSID. Abstract Data Type: octetArray Data Type Semantics: default Additional Information: Specified in Section 3 of [I-D.ietf-spring-srv6-path-segment]. Reference: This document. Although IE srhPsidIPv6 is used to identify an SRv6 path, this document doesn't limit using srhPsidIPv6 together with srhSegmentIPv6BasicList or srhSegmentIPv6ListSection in the same IPFIX message, see Section 4.2 for more information. 3.3. PSID Use Cases Network Observability, as described in [RFC9940], is the process of enabling network behavioral assessment through analysis of observed operational network data, and Network Telemetry (e.g., IPFIX) is the basis of Network Observability. PSID benefits the SR IPFIX flow visibility for Network Observability. As described in Section 3 of [RFC9545] and Section 2 of [I-D.ietf-spring-srv6-path-segment], SR-MPLS and SRv6 PSID may be Liu, et al. Expires 3 March 2027 [Page 6] Internet-Draft IPFIX for PSID August 2026 used to identify an SR Path in use cases such as performance measurement, bi-directional path association, end-to-end path protection, etc. By carrying PSID information in IPFIX messages, SR path of the traffic flow can be easily identified in the above use cases. To achieve operational visibility into SR networks, operators can leverage PSID information exported in IPFIX records in conjunction with the mapping between the PSID and the SR path context. This enables operational use cases such as: * Path selection visibility: Identifying which SR path a flow is using. * Policy selection visibility: Determining which SR Policy a flow is associated with. * Candidate-path churn detection: Observing PSID changes in subsequent Flow Records to detect path switches. * Performance measurement correlation: Associating performance metrics (e.g., delay, loss) with specific SR paths. The detailed procedures for correlating PSID with network events and diagnosing forwarding failures are deployment-specific and outside the scope of this document. 4. Operational Considerations 4.1. Generic Operational Considerations 4.1.1. PSID-to-Path Mapping Model The association between the exported PSID value and the corresponding SR path context (SR Policy, Candidate Path, or Segment List) can be established by the controller and signaled via BGP [I-D.ietf-idr-sr-policy-path-segment] or PCEP [I-D.ietf-pce-sr-path-segment]. Alternatively, the association can be instantiated on the ingress/egress node of the path and reported to the controller via PCEP [I-D.ietf-pce-sr-path-segment] or BGP-LS [I-D.ietf-idr-bgp-ls-sr-policy-path-segment]. Liu, et al. Expires 3 March 2027 [Page 7] Internet-Draft IPFIX for PSID August 2026 After decoding the IPFIX messages at the Collector, to get the flow record with the PSID, the Collector might process the flow record locally or send it to a data processing or analytics component. To recognize which SR path a PSID identifies, the analysis node needs to be aware of the association between the exported PSID value and the corresponding SR path context. This association can be obtained via the following methods: * querying a centralized controller, where the controller has already acquired the mapping through local configuration policy or protocols (e.g., PCEP [I-D.ietf-pce-sr-path-segment] or BGP-LS [I-D.ietf-idr-bgp-ls-sr-policy-path-segment]); * obtaining BGP-LS updates from headend nodes (or from a BGP-LS speaker in the network) [RFC9857] The detailed procedures for obtaining and maintaining this mapping are outside the scope of this document. 4.1.2. PSID Under Path Changes The following clarifications apply to the behavior of PSID when the network path changes: * Path asymmetry does not affect PSID export or identification. An IPFIX record always exports the PSID of the current unidirectional SR path. The existence or absence of a reverse path has no impact on the PSID value exported for the forward path. * Path degradation is unrelated to PSID exporting. PSID is a path identifier, not a path quality indicator. While PSID may be used to assist performance measurement (e.g., by associating telemetry data with a specific SR path), it does not itself reflect changes in path quality. * Under failover scenarios: If the SR path switches to a backup Candidate Path, the packet carries the PSID associated with the new path. The IPFIX Metering Process observes and exports the new PSID in subsequent Flow Records. If the SR path remains unchanged but Fast Reroute (FRR) or other local protection mechanisms are used, the Segment List (and thus the PSID) does not change. The exported PSID remains the same. Liu, et al. Expires 3 March 2027 [Page 8] Internet-Draft IPFIX for PSID August 2026 4.1.3. PSID Scope and Uniqueness As specified in [RFC9545] and [I-D.ietf-spring-srv6-path-segment], the same PSID value may be used to identify a single segment list, multiple segment lists, some or all segment lists under a Candidate Path, or some or all Candidate Paths within an SR Policy, depending on the use case. This flexibility allows operators to aggregate traffic statistics at different granularities. To avoid ambiguity in the exported PSID value, the entity (e.g., the controller, the ingress node, or the egress node of the path) that generates the association between the PSID and the SR path is responsible for ensuring that the exported PSID values are distinguishable within the intended scope (e.g., within a node, or the SR network domain). Reuse of the same PSID value outside its intended scope is undefined for correlation purposes. The Collector can resolve the association between an exported PSID value and the corresponding SR path by consulting the mapping information obtained from the entity responsible for the mapping, as described in Section 4.1.1. The detailed procedures for obtaining and maintaining this mapping are outside the scope of this document. 4.2. Operational Considerations for psidMplsLabelStackSection To generate Flow Records with psidMplsLabelStackSection, the Metering Process needs to acquire the information of the corresponding PSID, i.e., which label is the PSID. This may be achieved by configuration or signaling. How to get this information is out of the scope of this document. 4.3. Operational Considerations for srhPsidIPv6 As specified in [I-D.ietf-spring-srv6-path-segment], the G-Flag in the SRH is set to indicate that the last entry of the Segment List contains a 128-bit metadata object as an opaque identifier or data payload defined by the specific application (e.g., a Path Segment Identifier). To generate Flow Records with PSID included, the Metering Process MUST understand the G-Flag. Only when the G-Flag is set and the last entry carries an SRv6 PSID SHOULD the Metering Process capture the last entry in the SRH to get the PSID. If the G-Flag in the packet is unset or the last entry does not carry an SRv6 PSID, the srhPsidIPv6 SHOULD NOT be used in the template. When the srhPsidIPv6 appears in a Data Record with G-Flag unset, it SHOULD be ignored. As in [I-D.ietf-spring-srv6-path-segment] Section 3, the PSID allocation depends on the use cases, including: Liu, et al. Expires 3 March 2027 [Page 9] Internet-Draft IPFIX for PSID August 2026 * each segment list may have its own PSID with different value; * the same PSID may be used for some or all the segment list under a Candidate path; * the same PSID may be used for some or all Candidate Path within an SRv6 policy. If srhPsidIPv6 and srhSegmentIPv6BasicList/ srhSegmentIPv6ListSection appear together, the srhPsidIPv6 MAY be used to identify an SR Policy or candidate path, and the information carried in srhSegmentIPv6BasicList/srhSegmentIPv6ListSection shows the detailed segment list belonging to this SR Policy or candidate path. This document does not limit how to use srhPsidIPv6 and the detail is out of scope. 5. Security Considerations The export of PSID values in IPFIX records may reveal information about the SR path topology that is not exposed by standard 5-tuple flow records, including which SR paths exist and how traffic is distributed across them. An observer with access to the IPFIX data stream could potentially use this information to infer the SR network topology. Deployments should consider appropriate access controls for IPFIX data, as discussed in [RFC7011], to limit exposure of this information to authorized entities only. The security considerations of the underlying SR-MPLS PSID [RFC9545] and SRv6 PSID [I-D.ietf-spring-srv6-path-segment] also apply. 6. IANA Considerations This document requests IANA to create new IEs under the "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX]. +------------+---------------------------+-------------+ | Element ID | Name | Reference | +------------+---------------------------+-------------+ | TBD1 | psidMplsLabelStackSection | Section 3.1 | +------------+---------------------------+-------------+ | TBD2 | srhPsidIPv6 | Section 3.2 | +------------+---------------------------+-------------+ Table 1: IPFIX Information Elements Registry Liu, et al. Expires 3 March 2027 [Page 10] Internet-Draft IPFIX for PSID August 2026 7. Acknowledgements Thanks to Thomas Graf, Paul Aitken and Saumya Dikshit for their detailed review and comments. Thanks to Cheng Li and Chongfeng Xie for their helpful comments and suggestions. 8. References 8.1. Normative References [I-D.ietf-spring-srv6-path-segment] Li, C., Cheng, W., Zeng, G., Dhody, D., and Y. Zhu, "Path Segment Identifier (PSID) in SRv6 (Segment Routing in IPv6)", Work in Progress, Internet-Draft, draft-ietf- spring-srv6-path-segment-15, 15 March 2026, . [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, . [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . Liu, et al. Expires 3 March 2027 [Page 11] Internet-Draft IPFIX for PSID August 2026 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, . [RFC9545] Cheng, W., Ed., Li, H., Li, C., Ed., Gandhi, R., and R. Zigler, "Path Segment Identifier in MPLS-Based Segment Routing Networks", RFC 9545, DOI 10.17487/RFC9545, February 2024, . 8.2. Informative References [I-D.ietf-idr-bgp-ls-sr-policy-path-segment] Li, C., Li, Z., Zhu, Y., Cheng, W., and K. Talaulikar, "SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS", Work in Progress, Internet-Draft, draft- ietf-idr-bgp-ls-sr-policy-path-segment-12, 27 August 2026, . [I-D.ietf-idr-sr-policy-path-segment] Li, C., Li, Z., Yin, Y., Cheng, W., and K. Talaulikar, "SR Policy Extensions for Path Segment and Bidirectional Path", Work in Progress, Internet-Draft, draft-ietf-idr- sr-policy-path-segment-16, 29 June 2026, . [I-D.ietf-pce-sr-path-segment] Li, C., Chen, M., Cheng, W., Gandhi, R., and Q. Xiong, "Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR)", Work in Progress, Internet-Draft, draft-ietf-pce-sr-path- segment-15, 20 April 2026, . [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, DOI 10.17487/RFC5102, January 2008, . [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, DOI 10.17487/RFC5477, March 2009, . Liu, et al. Expires 3 March 2027 [Page 12] Internet-Draft IPFIX for PSID August 2026 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC9487] Graf, T., Claise, B., and P. Francois, "Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)", RFC 9487, DOI 10.17487/RFC9487, November 2023, . [RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F. Clad, Ed., "Compressed SRv6 Segment List Encoding", RFC 9800, DOI 10.17487/RFC9800, June 2025, . [RFC9857] Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H., and J. Tantsura, "Advertisement of Segment Routing Policies Using BGP - Link State", RFC 9857, DOI 10.17487/RFC9857, October 2025, . [RFC9940] Davis, N., Ed., Farrel, A., Ed., Graf, T., Wu, Q., and C. Yu, "Some Key Terms for Network Fault and Problem Management", RFC 9940, DOI 10.17487/RFC9940, April 2026, . Authors' Addresses Yao Liu ZTE Nanjing China Email: liu.yao71@zte.com.cn Zhenqiang Li China Mobile Email: lizhenqiang@chinamobile.com Yisong Liu China Mobile Email: liuyisong@chinamobile.com Changwang Lin New H3C Technologies Liu, et al. Expires 3 March 2027 [Page 13] Internet-Draft IPFIX for PSID August 2026 Email: linchangwang.04414@h3c.com Guozhen Dong China Telecom Email: donggz@chinatelecom.cn Liu, et al. Expires 3 March 2027 [Page 14]