<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that
    most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc submissionType="IETF" category="std" docName="draft-lin-opsawg-ipfix-sr-policy-00"
ipr="trust200902" consensus="true" updates="" xmlns:xi="http://www.w3.org/2001/XInclude">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: full3667, noModification3667, noDerivatives3667
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <title abbrev="Export of SR Policy Attr in IPFIX">
    Export of Segment Routing Policy Attributes in IP Flow Information Export (IPFIX)</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->
    <author fullname="Changwang Lin" initials="C." surname="Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>linchangwang.04414@h3c.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
	<author fullname="Zhenqiang Li" initials="Z"  surname="Li">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
      
    <!-- all of the following elements are optional -->
      <organization>China Mobile</organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <street>29 Finance Avenue, Xicheng District</street>
          <city>Beijing</city>
          <country>CN</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>lizhenqiang@chinamobile.com</email>  
        <!-- Can have more than one <email> element -->
      </address>
    </author>

    <date year="2026" />
    <!-- Meta-data Declarations -->
    <area>General</area>
    <workgroup>OPSAWG</workgroup>

    <keyword>IPFIX</keyword>
    <keyword>SR</keyword>
    <keyword>SRv6</keyword>
    <keyword>Policy</keyword>

<abstract>
<t>
	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.
</t>
</abstract>

  </front>

  <middle>

<section anchor="Introduction" title="Introduction">
<t>
	Segment Routing (SR) <xref target="RFC8402"/> and Segment Routing over IPv6 (SRv6) <xref target="RFC8986"/> have
  become widely deployed technologies for source routing and traffic engineering in modern networks.
  SR Policy <xref target="RFC9256"/> provides a mechanism to steer traffic through an ordered list of segments to meet
  Service Level Agreements (SLAs) and other operational requirements.
</t>
<t>
  An SR Policy is uniquely identified by the tuple <![CDATA[<]]>Headend, Color, Endpoint<![CDATA[>]]>, where:
</t>
<ul>
  <li>Headend: The node where the policy is instantiated.</li>
  <li>Color: A 32-bit numerical value representing the policy intent or class.</li>
  <li>Endpoint: The destination address of the policy (IPv4 or IPv6).</li>
</ul>
<t>
  While network operators can monitor traffic flows using IP Flow Information Export (IPFIX) <xref target="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:
</t>
<ul>
  <li>Service Assurance: Verifying that traffic is being forwarded according to the intended policy.</li>
  <li>Troubleshooting: Identifying which flows are affected when a policy fails.</li>
  <li>Routing Planning: Understanding traffic forwarding patterns per policy class.</li>
  <li>Security Monitoring: Detecting policy bypass or hijacking attempts.</li>
</ul>
<t>
  This document defines new IPFIX Information Elements (IEs) to export SR and SRv6 policy attributes (color, endpoint, and type)
  associated with observed IP flows. These IEs enable Exporting Processes to report which SR policy was applied to each flow,
  providing crucial visibility into the relationship between traffic and network policies.
</t>
</section>
<section anchor="Terminology" title="Terminology">
  <t>
    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 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all
    capitals, as shown here.
  </t>
  <t>
    This document makes use of the terms defined in <xref target="RFC7011"/>, and <xref target="RFC8402"/>.
  </t>
  <t>
    The following terms are used as defined in <xref target="RFC7011"/>:
  </t>
  <ul>
    <li>IPFIX</li>
    <li>IPFIX Information Elements</li>
  </ul>
  <t>
    The following terms are used as defined in <xref target="RFC8402"/>:
  </t>
  <ul>
    <li>Segment Routing (SR)</li>
    <li>SR-MPLS</li>
    <li>SRv6</li>
  </ul>
</section>
<section anchor="IPFIX IEs for SR Policy Attributes" title="IPFIX Information Elements for SR Policy Attributes">
<t>
  This section defines new IPFIX IEs for exporting SR Policy attributes.
</t>
<t>
  <list style="hanging">
    <t hangText="srPolicyColor"><vspace blankLines="0"/>
    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.
    </t>
    <t hangText="srPolicyEndpointIPv4"><vspace blankLines="0"/>
    The 32-bit IPv4 endpoint address of the SR Policy applied to the flow. 
    </t>
    <t hangText="srPolicyEndpointIPv6"><vspace blankLines="0"/>
    The 128-bit IPv6 endpoint address of the SR Policy applied to the flow.
    </t>
    <t hangText="srPolicyType"><vspace blankLines="0"/>
    The type of SR Policy applied to the flow. It is used to distinguish between SR-MPLS and SRv6 policies.
    </t>
  </list>
</t>
</section>

<section anchor="Operational Considerations" title="Operational Considerations">
<t>
  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.
</t>
<t>
  For srPolicyEndpointIPv4 and srPolicyEndpointIPv6 IE, A value of 0.0.0.0 for IPv4 address and ::0 for IPv6 address
  indicates that no SR Policy with an IPv4 or IPv6 endpoint was applied, or the endpoint is unknown. When these IEs is
  used with srPolicyColor IE, this pair uniquely identifies an SR Policy from the perspective of the headend node.
</t>
<t>
  When multiple SR Policies could apply to a flow (e.g., through policy nesting),
  these IEs defined in this document SHOULD report the value of the outermost or primary policy.
  These IEs are most meaningfully 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.
  To identify the headend node of an SR Policy,
  the exporterIPv4Address (130) and exporterIPv6Address (131) IEs can be used.
</t>
<t>
  These 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.
</t>
</section>

<section anchor="Security Considerations" title="Security Considerations">
<t>
	The Security Considerations for IPFIX <xref target="RFC7011"/> apply to this document as well.
</t>
<t>
  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 <xref target="RFC7011"/> or DTLS <xref target="RFC9147"/>.
</t>
<t>
  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.
</t>
<t>
  While SR Policy attributes themselves don't directly identify individuals, they could be 
  combined with other flow data to infer sensitive information about network usage patterns.
</t>
<t>
  Exporting additional IEs increases the size of flow records and template 
  definitions. Exporting Processes SHOULD implement appropriate rate limiting and resource controls.
</t>
<t>
  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.
</t>
</section>

<section anchor="IANA Considerations" title="IANA Considerations">
  <section anchor="SR Policy Attributes IPFIX IEs" title="New IPFIX IEs for SR Policy Attributes">
    <t>
      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 <xref target="IANA-IPFIX"/>.
    </t>
    <t>
      Table 1 lists the new IPFIX IEs for SR Policy Attributes:
    </t>
    <t><figure>
      <artwork align="center" name="Table 1"><![CDATA[
   +============+========================+===============+
   | Element ID | Name                   | Reference     |
   +============+========================+===============+
   | TBD1       | srPolicyColor          | This document |
   +------------+------------------------+---------------+
   | TBD2       | srPolicyEndpointIPv4   | This document |
   +------------+------------------------+---------------+
   | TBD3       | srPolicyEndpointIPv6   | This document |
   +------------+------------------------+---------------+
   | TBD4       | srPolicyType           | This document |
   +------------+------------------------+---------------+

Table 1: New IEs in the "IPFIX Information Elements" Registry]]></artwork>
    </figure></t>
    <section anchor="IANAsrPolicyColor" title="srPolicyColor">
      <dl>
        <dt>Name:</dt><dd>srPolicyColor</dd>
      </dl>
      <dl>
        <dt>Element ID:</dt><dd>TBD1</dd>
      </dl>
      <dl>
        <dt>Description:</dt>
        <dd>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.</dd>
      </dl>
      <dl>
        <dt>Abstract Data Type:</dt><dd>unsigned32</dd>
      </dl>
      <dl>
        <dt>Data Type Semantics:</dt><dd>identifier</dd>
      </dl>
      <dl>
        <dt>Status:</dt><dd>current</dd>
      </dl>
      <dl>
        <dt>Reference:</dt><dd>[this document]</dd>
      </dl>
    </section>
    <section anchor="IANAsrPolicyEndpointIPv4" title="srPolicyEndpointIPv4">
      <dl>
        <dt>Name:</dt><dd>srPolicyEndpointIPv4</dd>
      </dl>
      <dl>
        <dt>Element ID:</dt><dd>TBD2</dd>
      </dl>
      <dl>
        <dt>Description:</dt>
        <dd>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,
            or the endpoint is unknown.</dd>
      </dl>
      <dl>
        <dt>Abstract Data Type:</dt><dd>ipv4Address</dd>
      </dl>
      <dl>
        <dt>Data Type Semantics:</dt><dd>identifier</dd>
      </dl>
      <dl>
        <dt>Status:</dt><dd>current</dd>
      </dl>
      <dl>
        <dt>Reference:</dt><dd>[this document]</dd>
      </dl>
    </section>
    <section anchor="IANAsrPolicyEndpointIPv6" title="srPolicyEndpointIPv6">
      <dl>
        <dt>Name:</dt><dd>srPolicyEndpointIPv6</dd>
      </dl>
      <dl>
        <dt>Element ID:</dt><dd>TBD3</dd>
      </dl>
      <dl>
        <dt>Description:</dt>
        <dd>The IPv6 endpoint address of the Segment Routing Policy applied to the flow.
            The ::0 address indicates that no SR Policy with an IPv6 endpoint was applied,
            or the endpoint is unknown.</dd>
      </dl>
      <dl>
        <dt>Abstract Data Type:</dt><dd>ipv6Address</dd>
      </dl>
      <dl>
        <dt>Data Type Semantics:</dt><dd>identifier</dd>
      </dl>
      <dl>
        <dt>Status:</dt><dd>current</dd>
      </dl>
      <dl>
        <dt>Reference:</dt><dd>[this document]</dd>
      </dl>
    </section>
    <section anchor="IANAsrPolicyType" title="srPolicyType">
      <dl>
        <dt>Name:</dt><dd>srPolicyType</dd>
      </dl>
      <dl>
        <dt>Element ID:</dt><dd>TBD4</dd>
      </dl>
      <dl>
        <dt>Description:</dt>
        <dd>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</dd>
      </dl>
      <dl>
        <dt>Abstract Data Type:</dt><dd>unsigned8</dd>
      </dl>
      <dl>
        <dt>Data Type Semantics:</dt><dd>identifier</dd>
      </dl>
      <dl>
        <dt>Status:</dt><dd>current</dd>
      </dl>
      <dl>
        <dt>Reference:</dt><dd>[this document]</dd>
      </dl>
    </section>
  </section>
  <section anchor="Sub-Registry for SR Policy Types" title="IPFIX Sub-Registry for SR Policy Types">
    <t>
      IANA is requested to create a new sub-registry titled "SR Policy Types" under
      the "IPFIX Information Elements" registry.
    </t>
    <t><figure>
      <artwork align="center" name="Table 2"><![CDATA[
+=======+=====================================+===============+
| 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]]></artwork>
    </figure></t>
  </section>
</section>

<!-- <section anchor="Acknowledgements" title="Acknowledgements">
<t>
	The author would like to thank xxx for his valuable input.
</t>
</section> -->

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
  <references title="References">
    <references title="Normative References">
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
        <!--<?rfc include="reference.I-D.li-dmsc-architecture.xml"?>-->
    </references>
    <references title="Informative References">
        <reference anchor="IANA-IPFIX"
                 target="https://www.iana.org/assignments/ipfix/ipfix.xhtml">
          <front>
            <title>IP Flow Information Export (IPFIX) Entities</title>

            <author/>

            <date>n.d.</date>
          </front>
        </reference>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
    </references>
  </references>
  </back>
</rfc>
