Export of Segment Routing Policy Attributes in IP Flow Information Export (IPFIX)

Segment Routing (SR) and Segment Routing over IPv6 (SRv6) have become widely deployed technologies for source routing and traffic engineering in modern networks. SR Policy 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:

Headend: The node where the policy is instantiated.
Color: A 32-bit numerical value representing the policy intent or class.
Endpoint: The destination address of the policy (IPv4 or IPv6).

While network operators can monitor traffic flows using IP Flow Information Export (IPFIX) 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:

Service Assurance: Verifying that traffic is being forwarded according to the intended policy.
Troubleshooting: Identifying which flows are affected when a policy fails.
Routing Planning: Understanding traffic forwarding patterns per policy class.
Security Monitoring: Detecting policy bypass or hijacking attempts.
Per-Policy Traffic Monitoring: Monitoring real-time performance metrics (such as transmitted/dropped packet counts) for individual SR Policies.

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 when, and only when, they appear in all capitals, as shown here. This document makes use of the terms defined in , and . The following terms are used as defined in :

IPFIX
IPFIX Information Elements

The following terms are used as defined in :

Segment Routing (SR)
SR-MPLS
SRv6

This section defines new IPFIX IEs for exporting SR Policy attributes. The IPv4 address of the headend node encapsulating the SR policy, identifying the SR Policy headend node. This address is typically the loopback address of the headend device. The IPv6 address of the headend node encapsulating the SR policy, identifying the SR Policy headend node. This address is typically the loopback address of the headend device. The color value of the SR Policy applied to the flow. The color is a 32-bit unsigned integer that identifies the intent or class of the SR Policy. The 32-bit IPv4 endpoint address of the SR Policy applied to the flow. The 128-bit IPv6 endpoint address of the SR Policy applied to the flow. The type of SR Policy applied to the flow. It is used to distinguish between SR-MPLS and SRv6 policies.

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 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 or DTLS . 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 . Table 1 lists the new IPFIX IEs for SR Policy Attributes:

Name:: srPolicyHeadendIPv4Address

Element ID:: TBD1

Description:: The IPv4 address of the headend node encapsulating the SR policy, identifying the SR Policy headend node. This address is typically the loopback address of the headend device.

Abstract Data Type:: ipv4Address

Data Type Semantics:: identifier

Status:: current

Reference:: [this document]

Name:: srPolicyHeadendIPv6Address

Element ID:: TBD2

Description:: The IPv6 address of the headend node encapsulating the SR policy, identifying the SR Policy headend node. This address is typically the loopback address of the headend device.

Abstract Data Type:: ipv6Address

Data Type Semantics:: identifier

Status:: current

Reference:: [this document]

Name:: srPolicyColor

Element ID:: TBD3

Description:: The color value of the SR Policy applied to the flow. The color is a 32-bit unsigned integer that identifies the intent or class of the SR Policy. A value of 0 indicates that no SR Policy was applied to the flow.

Abstract Data Type:: unsigned32

Data Type Semantics:: identifier

Status:: current

Reference:: [this document]

Name:: srPolicyEndpointIPv4

Element ID:: TBD4

Description:: The IPv4 endpoint address of the Segment Routing Policy applied to the flow. A value of 0.0.0.0 indicates that no SR Policy with an IPv4 endpoint was applied to the flow.

Abstract Data Type:: ipv4Address

Data Type Semantics:: identifier

Status:: current

Reference:: [this document]

Name:: srPolicyEndpointIPv6

Element ID:: TBD5

Description:: The IPv6 endpoint address of the Segment Routing Policy applied to the flow. The ::/128 (all zeros) address indicates that no SR Policy with an IPv6 endpoint was applied to the flow.

Abstract Data Type:: ipv6Address

Data Type Semantics:: identifier

Status:: current

Reference:: [this document]

Name:: srPolicyType

Element ID:: TBD6

Description:: The type of Segment Routing Policy applied to the flow. A value of 0 indicates the policy type is unknown or not applicable. Values are defined in the "SR Policy Types" sub-registry

Abstract Data Type:: unsigned8

Data Type Semantics:: identifier

Status:: current

Reference:: [this document]

IANA is requested to create a new sub-registry titled "SR Policy Types" under the "IPFIX Information Elements" registry.