Export of Path Segment Identifier Information in IPFIX
draft-ietf-opsawg-ipfix-path-segment-01
| Document | Type | Active Internet-Draft (opsawg WG) | |
|---|---|---|---|
| Authors | Yao Liu , Zhenqiang Li , Yisong Liu , Changwang Lin , Guozhen Dong | ||
| Last updated | 2025-11-02 | ||
| Replaces | draft-liu-opsawg-ipfix-path-segment | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-opsawg-ipfix-path-segment-01
OPSAWG Y. Liu
Internet-Draft ZTE
Intended status: Standards Track Z. Li
Expires: 6 May 2026 Y. Liu
China Mobile
C. Lin
New H3C Technologies
G. Dong
China Telecom
2 November 2025
Export of Path Segment Identifier Information in IPFIX
draft-ietf-opsawg-ipfix-path-segment-01
Abstract
This document introduces new IPFIX Information Elements to identify
the Path Segment Identifier(PSID)s 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 6 May 2026.
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
Liu, et al. Expires 6 May 2026 [Page 1]
Internet-Draft IPFIX for PSID November 2025
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 . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . . . 5
3.3. PSID Usecases . . . . . . . . . . . . . . . . . . . . . . 6
4. Operational Considerations . . . . . . . . . . . . . . . . . 6
4.1. Operational Considerations for psidMpls . . . . . . . . . 6
4.2. Operational Considerations for srhPsidIPv6 . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
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're still some
shortcomings with the existing mechanisms.
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,
Liu, et al. Expires 6 May 2026 [Page 2]
Internet-Draft IPFIX for PSID November 2025
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 more larger when the segment list
contains many SIDs.
* 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[I-D.ietf-spring-srv6-srh-compression], additional
information and processing procedures are required to decode
compressed-SID containers as described in [RFC9487] section 6.2 to
obtain the original segment list information before compression.
Liu, et al. Expires 6 May 2026 [Page 3]
Internet-Draft IPFIX for PSID November 2025
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 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.
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], [RFC9545] and [I-D.ietf-spring-srv6-srh-compression].
The following terms are used as defined in [RFC7011]:
* IPFIX
* IPFIX Information Elements
* Metering Process
* Template Record
* Data Record
* Collector
The following terms are used as defined in [RFC8402]:
* Segment Routing (SR)
* Segment List
Liu, et al. Expires 6 May 2026 [Page 4]
Internet-Draft IPFIX for PSID November 2025
* 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 "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.
Name: psidMpls
ElementID: TBD1
Description: The 24-bit field carrying the Label, Exp, and S of the
MPLS label stack entry that contains an SR-MPLS PSID.
Abstract Data Type: octetArray
Data Type Semantics: identifier
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 IPv6 address that represents an
SRv6 PSID.
Name: srhPsidIPv6
ElementID: TBD2
Description: The 128-bit IPv6 address that represents an SRv6 PSID.
Liu, et al. Expires 6 May 2026 [Page 5]
Internet-Draft IPFIX for PSID November 2025
Abstract Data Type: ipv6Address
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 Usecases
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.
4. Operational Considerations
4.1. Operational Considerations for psidMpls
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.
Liu, et al. Expires 6 May 2026 [Page 6]
Internet-Draft IPFIX for PSID November 2025
4.2. Operational Considerations for srhPsidIPv6
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:
* 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
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.
Liu, et al. Expires 6 May 2026 [Page 7]
Internet-Draft IPFIX for PSID November 2025
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 | psidMpls | Section 3.1 |
+------------+-------------+-------------+
| TBD2 | srhPsidIPv6 | Section 3.2 |
+------------+-------------+-------------+
Table 1: IPFIX Information Elements
Registry
7. Acknowledgement
Thanks to Thomas Graf for his 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., Chen, M., 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-13, 13 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-path-segment-13>.
[IANA-IPFIX]
IANA, "IP Flow Information Export (IPFIX) Entities",
<https://www.iana.org/assignments/ipfix>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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,
<https://www.rfc-editor.org/info/rfc7011>.
Liu, et al. Expires 6 May 2026 [Page 8]
Internet-Draft IPFIX for PSID November 2025
[RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
for IP Flow Information Export (IPFIX)", RFC 7012,
DOI 10.17487/RFC7012, September 2013,
<https://www.rfc-editor.org/info/rfc7012>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc8402>.
[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,
<https://www.rfc-editor.org/info/rfc8754>.
8.2. Informative References
[I-D.ietf-nmop-terminology]
Davis, N., Farrel, A., Graf, T., Wu, Q., and C. Yu, "Some
Key Terms for Network Fault and Problem Management", Work
in Progress, Internet-Draft, draft-ietf-nmop-terminology-
23, 18 August 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-nmop-
terminology-23>.
[I-D.ietf-spring-srv6-srh-compression]
Cheng, W., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, "Compressed SRv6 Segment List Encoding (CSID)", Work
in Progress, Internet-Draft, draft-ietf-spring-srv6-srh-
compression-23, 6 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-23>.
[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,
<https://www.rfc-editor.org/info/rfc5102>.
[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,
<https://www.rfc-editor.org/info/rfc5477>.
Liu, et al. Expires 6 May 2026 [Page 9]
Internet-Draft IPFIX for PSID November 2025
[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,
<https://www.rfc-editor.org/info/rfc8660>.
[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, <https://www.rfc-editor.org/info/rfc9487>.
[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, <https://www.rfc-editor.org/info/rfc9545>.
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
Email: linchangwang.04414@h3c.com
Guozhen Dong
China Telecom
Email: donggz@chinatelecom.cn
Liu, et al. Expires 6 May 2026 [Page 10]