| Internet-Draft | IPFIX for PSID | September 2025 |
| Liu, et al. | Expires 15 March 2026 | [Page] |
This document introduces new IPFIX Information Elements to identify the Path Segment Identifier(PSID)s for SR-MPLS and SRv6 paths identification.¶
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 15 March 2026.¶
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.¶
When monitoring a traffic flow in an SR network, a typical use case is to answer the following questions:¶
To answer these questions, when exporting IPFIX flow records, the SR path information needs to be included. However, there're still some shortcomings with the existing mechanisms.¶
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:¶
[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:¶
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 as 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.¶
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], [RFC9545] and [I-D.ietf-spring-srv6-srh-compression].¶
The following terms are used as defined in [RFC7011]:¶
The following terms are used as defined in [RFC8402]:¶
The following terms are used as defined in [RFC8754]:¶
The following terms are used as defined in [RFC9545] and [I-D.ietf-spring-srv6-path-segment]:¶
A new IE "psidMpls" is defined in this document to identify the SR-MPLS PSID, it carries a 32-bit MPLS label that represents an SR-MPLS PSID.¶
A new IE "srhPsidIPv6" is defined in this document to identify the PSID in the SRH, it carries a 128-bit IPv6 address that represents an SRv6 PSID.¶
srhPsidIPv6¶
TBD2¶
The 128-bit IPv6 address that represents an SRv6 PSID.¶
ipv6Address¶
default¶
Specified in Section 3 of [I-D.ietf-spring-srv6-path-segment].¶
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.¶
Network Observability, as described in [I-D.ietf-nmop-terminology], 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 [RFC9545] section 3 and [I-D.ietf-spring-srv6-path-segment] section 2, SR-MPLS and SRv6 PSID may be used to identify an SR Path in use cases such as performance measurement, bi-directional path association, end-to-end path protection and etc. By carrying PSID information in IPFIX messages, SR path of the traffic flow can be easily identified in the above uses cases.¶
To generate Flow Records with psidMpls, 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 the is out of the scope of this document.¶
After decoding the IPFIX messages at the collector, to get the flow record with PSID, the collector might process the flow record locally or send it to a data processing or analytics component. In order to recognize the SR path, the analysis node SHOULD be aware of which SR path the SR-MPLS PSID identifies. How to get this information the is out of the scope of this document.¶
As specified in [I-D.ietf-spring-srv6-path-segment], the P-flag in the SRH is set to indicate the presence of PSID. To generate Flow Records with PSID included, the metering process MUST understand the P-flag. Only when the P-flag is set SHOULD the metering process capture the last entry in the SRH to get the PSID. If the P-flag in the packet is unset, when the srhPsidIPv6 appears in the template record, the corresponding field in the data record is RECOMMENDED to set to all zero.¶
After decoding the IPFIX messages at the collector, to get the flow record with SRv6 PSID, the collector might process the flow record locally or send it to a data processing or analytics component. In order to recognize the SR path, the analysis node SHOULD be aware of which SR path the SRv6 PSID identifies. How to get this information the is out of the scope of this document.¶
As in [I-D.ietf-spring-srv6-path-segment] section 3, the PSID allocation depends on the use cases, including:¶
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.¶
There are no additional security considerations regarding allocation of these new IPFIX IEs compared to [RFC7012].¶
Other security considerations for SR-MPLS PSID in [RFC9545] and for SRv6 PSID described in [I-D.ietf-spring-srv6-path-segment] apply to this document.¶
This document requests IANA to create new IEs under the "IPFIX Information Elements" registry [RFC7012] available at [IANA-IPFIX].¶
+-------+--------------------------------+
|Element| Name | Reference |
| ID | | |
+-------+-----------------+--------------+
| TBD1 | psidMpls |This document |
+-------+-----------------+--------------+
| TBD2 | srhPsidIPv6 |This document |
+-------+-----------------+--------------+
¶
The authors would like to thank Thomas Graf, Cheng Li and Chongfeng Xie for their helpful comments and suggestions.¶