Export of Segment Routing Path Segment Identifier (PSID) Information in IPFIX
draft-ietf-opsawg-ipfix-path-segment-07

OPSAWG                                                            Y. Liu
Internet-Draft                                                       ZTE
Intended status: Standards Track                                   Z. Li
Expires: 1 April 2027                                             Y. Liu
                                                            China Mobile
                                                                  C. Lin
                                                    New H3C Technologies
                                                                 G. Dong
                                                           China Telecom
                                                       28 September 2026

Export of Segment Routing Path Segment Identifier (PSID) Information in
                                 IPFIX
                draft-ietf-opsawg-ipfix-path-segment-07

Abstract

   This document introduces new IPFIX Information Elements to identify
   the Segment Routing (SR) Path Segment Identifier (PSID) for SR-MPLS
   and SRv6 path 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 1 April 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 1 April 2027                  [Page 1]
Internet-Draft               IPFIX for PSID               September 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 . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  SR-MPLS PSID in IPFIX . . . . . . . . . . . . . . . . . .   6
     3.2.  SRv6 PSID in IPFIX  . . . . . . . . . . . . . . . . . . .   6
     3.3.  PSID Use Cases  . . . . . . . . . . . . . . . . . . . . .   7
   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
     4.1.  Generic Operational Considerations  . . . . . . . . . . .   8
       4.1.1.  PSID-to-Path Mapping Model  . . . . . . . . . . . . .   8
       4.1.2.  PSID Under Path Changes . . . . . . . . . . . . . . .   8
       4.1.3.  PSID Scope and Uniqueness . . . . . . . . . . . . . .   9
     4.2.  Operational Considerations for
           psidMplsLabelStackSection . . . . . . . . . . . . . . . .  10
     4.3.  Operational Considerations for srhPsidIPv6  . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Segment Routing (SR) [RFC8402] allows a headend node to steer a
   packet flow along a specific path.  [RFC9256] further details the
   concepts of SR Policy.  An SR Policy consists of one or more
   candidate paths, each comprising one or more segment lists.

   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 ?

Liu, et al.               Expires 1 April 2027                  [Page 2]
Internet-Draft               IPFIX for PSID               September 2026

   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.

1.1.  SR-MPLS Path Identification

   In SR-MPLS [RFC8402], a segment is encoded as an MPLS label.  For
   MPLS label stack information collection, IPFIX Information Element
   (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: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 of the SR path 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 Flow
      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 segment list information of the traffic flow.

1.2.  SRv6 Path Identification

   [RFC9487] introduces new IP Flow Information Export (IPFIX) 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 srhSegmentIPv6BasicList or srhSegmentIPv6ListSection, but
   the segment list is not always the best key identifier due to the
   following reasons:

Liu, et al.               Expires 1 April 2027                  [Page 3]
Internet-Draft               IPFIX for PSID               September 2026

   *  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.

   *  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) [RFC8402] 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 path 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], [RFC9256] and [RFC9545].

   The following terms are used as defined in [RFC7011]:

   *  IPFIX

   *  IPFIX Information Elements

Liu, et al.               Expires 1 April 2027                  [Page 4]
Internet-Draft               IPFIX for PSID               September 2026

   *  Metering Process

   *  Template Record

   *  Flow Record

   *  Collector

   The following terms are used as defined in [RFC8402]:

   *  Segment Routing (SR)

   *  SID

   *  SRLB

   *  SR-MPLS

   *  SRv6

   The following terms are used as defined in [RFC9256]:

   *  SR Policy

   *  headend node

   *  candidate path

   *  segment list

   The following terms are used as defined in [RFC8754]:

   *  SRH

   *  Last Entry

   The following term is used as defined in [RFC9545]:

   *  PSID: Path Segment Identifier

   The following term is used as defined in
   [I-D.ietf-spring-srv6-path-segment]:

   *  G-Flag: The G bit in the SRH used to indicate that the last entry
      of the segment list contains a 128-bit metadata object (such as a
      Path Segment Identifier) as defined in
      [I-D.ietf-spring-srv6-path-segment].

Liu, et al.               Expires 1 April 2027                  [Page 5]
Internet-Draft               IPFIX for PSID               September 2026

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 contains 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

      Exp: Experimental Use, 3 bits

      S: Bottom of Stack, 1 bit

   Abstract Data Type:  octetArray

   Data Type Semantics:  default

   Additional Information:  See [RFC9545] for the definition of the MPLS
      PSID.  The encoding of the Label, Exp, and S fields follows the
      MPLS label stack entry format defined in [RFC3032].

   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.  This IE carries a 128-bit value that represents an
   SRv6 PSID.

   Name:  srhPsidIPv6

   ElementID:  TBD2

Liu, et al.               Expires 1 April 2027                  [Page 6]
Internet-Draft               IPFIX for PSID               September 2026

   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.3 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
   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, the
   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.

Liu, et al.               Expires 1 April 2027                  [Page 7]
Internet-Draft               IPFIX for PSID               September 2026

   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].

   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.

Liu, et al.               Expires 1 April 2027                  [Page 8]
Internet-Draft               IPFIX for PSID               September 2026

   *  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.

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.

   To correctly interpret an exported PSID value, a Collector or any
   intermediary processing IPFIX data records needs to be aware of the
   scope within which the PSID is distinguishable.  While the specific
   mechanisms for a Collector to learn and respect this scope are
   deployment-specific and outside the scope of this document,
   implementers should note that failing to account for the PSID's scope
   can lead to ambiguous or incorrect correlation of flow records.

Liu, et al.               Expires 1 April 2027                  [Page 9]
Internet-Draft               IPFIX for PSID               September 2026

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 Flow 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:

   *  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 paths 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.

Liu, et al.               Expires 1 April 2027                 [Page 10]
Internet-Draft               IPFIX for PSID               September 2026

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

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              srv6-path-segment-15>.

Liu, et al.               Expires 1 April 2027                 [Page 11]
Internet-Draft               IPFIX for PSID               September 2026

   [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>.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
              <https://www.rfc-editor.org/info/rfc3032>.

   [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>.

   [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>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [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>.

Liu, et al.               Expires 1 April 2027                 [Page 12]
Internet-Draft               IPFIX for PSID               September 2026

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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-
              ls-sr-policy-path-segment-12>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-
              policy-path-segment-16>.

   [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,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-sr-
              path-segment-15>.

   [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>.

   [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>.

   [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,
              <https://www.rfc-editor.org/info/rfc9800>.

Liu, et al.               Expires 1 April 2027                 [Page 13]
Internet-Draft               IPFIX for PSID               September 2026

   [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,
              <https://www.rfc-editor.org/info/rfc9857>.

   [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,
              <https://www.rfc-editor.org/info/rfc9940>.

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 1 April 2027                 [Page 14]