| Internet-Draft | Export of SR Policy Attr in IPFIX | June 2026 |
| Lin, et al. | Expires 31 December 2026 | [Page] |
This document defines new IP Flow Information Export (IPFIX) Information Elements (IEs) to export attributes of Segment Routing (SR) and Segment Routing over IPv6 (SRv6) policies applied to IP flows, which enables correlation between observed traffic flows and the SR/SRv6 policies that carry them.¶
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 31 December 2026.¶
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 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.¶
Segment Routing (SR) [RFC8402] and Segment Routing over IPv6 (SRv6) [RFC8986] have become widely deployed technologies for source routing and traffic engineering in modern networks. SR Policy [RFC9256] provides a mechanism to steer traffic through an ordered list of segments to meet Service Level Agreements (SLAs) and other operational requirements.¶
An SR Policy is uniquely identified by the tuple <Headend, Color, Endpoint>, where:¶
While network operators can monitor traffic flows using IP Flow Information Export (IPFIX) [RFC7011] and observe which SR policies are configured in the network, there has been no standardized way to correlate individual IP flows with the specific SR policies that carry them. This correlation is essential for:¶
This document defines new IPFIX Information Elements (IEs) to export SR and SRv6 policy attributes (headend, color, endpoint, and type) associated with observed IP flows. These IEs enable Exporting Processes to report which SR policy was applied to each flow and where, providing crucial visibility into the relationship between traffic and network policies.¶
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], and [RFC8402].¶
This section defines new IPFIX IEs for exporting SR Policy attributes.¶
This section outlines representative deployment scenarios where the extensions defined in this document provide significant value.¶
Operators need to verify that traffic for critical services (e.g., VoIP, financial transactions) is indeed being forwarded along the intended SR Policy path and meeting predefined Service Level Agreements (SLAs).¶
In this case, the monitored "flow" is defined by the SR Policy identifier (Headend, Endpoint, Color, and Type), representing all packets belonging to that service class.¶
It enables direct, policy-level measurement of performance metrics (latency, loss, jitter) against SLAs. This moves assurance from the network-wide inference to per-service, per-path validation.¶
When a service degradation occurs, rapid isolation of the fault domain is critical. This use case focuses on identifying if an issue is localized to a specific SR Policy.¶
In this case, the "flow" is again keyed by the SR Policy. By comparing metrics across different policies sharing network segments, the faulty component can be isolated.¶
It dramatically reduces Mean Time to Repair (MTTR) by answering the question: "Is this a general network problem or a problem specific to my policy for Service X?"¶
Network planners require an understanding of actual traffic distribution across different SR Policy paths to optimize network resources and plan for capacity upgrades.¶
Here, the "flow" per SR Policy provides the atomic unit of analysis for traffic volume (byte/packet counts) over time.¶
It provides a clear, intent-based view of traffic matrices, showing how much traffic each policy class carries. This data is essential for validating the efficacy of traffic engineering decisions and for predictive capacity planning.¶
Detecting deviations from intended forwarding paths is crucial for security. This includes identifying potential policy bypass, hijacking, or unexpected traffic attraction to a specific policy.¶
A baseline of normal "flow" volumes and paths per SR Policy is established. Deviations from this baseline trigger alerts.¶
It provides a new layer of control-plane/data-plane consistency checking. Unexpected traffic appearing on, or disappearing from, a policy can be a key security indicator.¶
This is the granular, real-time monitoring of performance metrics for individual SR Policies, forming the foundation for the use cases above.¶
The "flow" record is anchored to a single SR Policy and contains Key Performance Indicators (KPIs) as non-key fields.¶
It delivers fundamental visibility into the health of each logical path, providing metrics such as forwarded/dropped packet counts. This is the primary data source for service dashboards and automated diagnostics.¶
For 'srPolicyHeadendIPv4Address' and 'srPolicyHeadendIPv6Address' IEs, Implementers SHOULD select the appropriate IE based on the actual address family of the SR policy. For a pure IPv4 environment, use only 'srPolicyHeadendIPv4Address'. For a pure IPv6 environment, use only 'srPolicyHeadendIPv6Address'. For a dual-stack environment, use the corresponding IE identifying the SR policy headend node in the IPFIX record according to the address family of the specific SR policy. A single flow record SHOULD NOT contain both IEs simultaneously.¶
For 'srPolicyColor' IE, a value of 0 indicates that no SR Policy was applied to the flow (i.e., the flow was forwarded using conventional routing). Color values are locally significant to the headend node but are often coordinated network-wide to represent consistent service classes.¶
For 'srPolicyEndpointIPv4' and 'srPolicyEndpointIPv6' IEs, A value of 0.0.0.0 for IPv4 address and ::/128 (all zeros) for IPv6 address indicates that no SR Policy with an IPv4 or IPv6 endpoint was applied to the flow. When these IEs is used with 'srPolicyColor' IE, this pair uniquely identifies an SR Policy from the perspective of the headend node.¶
When multiple SR Policies could apply to a flow (e.g., through policy nesting), all IEs defined in this document SHOULD report the value of the outermost or primary policy. These IEs about SR Policy attributes are only collected and reported by the headend node of the SR Policy - that is, the node where the policy is instantiated and where packets enter the SR Policy path.¶
In this document, all IEs about SR Policy attributes complement existing IPFIX IEs. When reporting SR Policy attributes, Exporting Processes SHOULD also include basic flow identification IEs such as source/destination addresses, protocol, and ports to provide context for the policy application.¶
The Security Considerations for IPFIX [RFC7011] apply to this document as well.¶
SR Policy attributes reveal network engineering decisions and traffic steering policies. Unauthorized access to this information could aid in traffic analysis or network reconnaissance. Export of these IEs SHOULD be protected using IPFIX over TLS [RFC7011] or DTLS [RFC9147].¶
Manipulation of SR Policy attributes in flow records could mislead network operators about traffic paths, potentially hiding policy violations or attacks. Collecting Processes SHOULD verify data integrity when possible.¶
While SR Policy attributes deliver vital operational insights into business traffic patterns, their correlation with flow data can reveal internal system relationships. Consequently, their implementation SHOULD incorporate data governance measures to ensure utility is balanced with the protection of sensitive operational information.¶
Exporting additional IEs increases the size of flow records and template definitions. Exporting Processes SHOULD implement appropriate rate limiting and resource controls.¶
The ability to correlate flows with policies enables verification that traffic is following intended paths, which can help detect policy bypass attacks or configuration errors.¶
This document specifies new IPFIX IEs to enable export of SR Policy Attributes along with other flow information. This document requests IANA to add these IPFIX IEs to the "IPFIX Information Elements" registry available at [IANA-IPFIX].¶
Table 1 lists the new IPFIX IEs for SR Policy Attributes:¶
+============+============================+===============+ | Element ID | Name | Reference | +============+============================+===============+ | TBD1 | srPolicyHeadendIPv4Address | This document | +------------+----------------------------+---------------+ | TBD2 | srPolicyHeadendIPv6Address | This document | +------------+----------------------------+---------------+ | TBD3 | srPolicyColor | This document | +------------+----------------------------+---------------+ | TBD4 | srPolicyEndpointIPv4 | This document | +------------+----------------------------+---------------+ | TBD5 | srPolicyEndpointIPv6 | This document | +------------+----------------------------+---------------+ | TBD6 | srPolicyType | This document | +------------+----------------------------+---------------+ Table 1: New IEs in the "IPFIX Information Elements" Registry¶
IANA is requested to create a new sub-registry titled "SR Policy Types" under the "IPFIX Information Elements" registry.¶
+=======+=====================================+===============+
| Value | Description | Reference |
+=======+=====================================+===============+
| 0 | Unknown or unspecified policy type | This document |
+-------+-------------------------------------+---------------+
| 1 | SR-MPLS policy | This document |
+-------+-------------------------------------+---------------+
| 2 | SRv6 policy | This document |
+-------+-------------------------------------+---------------+
| 255 | Reserved for experimentation | This document |
+-------+-------------------------------------+---------------+
Table 2: SR Policy Types Sub-Registry¶