<?xml version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-ietf-opsawg-ipfix-path-segment-01"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

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

 <front>
   <title abbrev="IPFIX for PSID">Export of Path Segment Identifier Information in IPFIX</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ipfix-path-segment-01"/>
   <author fullname="Yao Liu" surname="Liu">
      <organization>ZTE</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>liu.yao71@zte.com.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Zhenqiang Li" surname="Li">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone></phone>
        <email>lizhenqiang@chinamobile.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Yisong Liu" surname="Liu">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone></phone>
        <email>liuyisong@chinamobile.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	
   <author fullname="Changwang Lin" surname="Lin">
      <organization>New H3C Technologies</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone></phone>
        <email>linchangwang.04414@h3c.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
   <author fullname="Guozhen Dong" surname="Dong">
      <organization>China Telecom</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->

         <city></city>
          <region/>
          <code/>
          <country></country>
        </postal>
        <phone></phone>
        <email>donggz@chinatelecom.cn</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>	
    <date year="2025"/>

   <!-- Meta-data Declarations -->

   <area>OPS</area>
    <workgroup>OPSAWG</workgroup>
    <!-- WG name at the upperleft corner of the doc,
        IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
        which is used by the RFC Editor as a nod to the history of the IETF. -->

   <keyword>IPFIX</keyword>
   <keyword>SR</keyword>
   <keyword>Path Segment</keyword>
    <!-- Keywords will be incorporated into HTML output
        files in a meta tag but they have no effect on text or nroff
        output. If you submit your draft to the RFC Editor, the
        keywords will be used for the search engine. -->

   <abstract>
      <t>This document introduces new IPFIX Information Elements to identify the Path Segment Identifier(PSID)s for SR-MPLS and SRv6 paths identification.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>  
	<t>When monitoring a traffic flow in an SR network, a typical use case is to answer the following questions:</t>
		<ul spacing="normal">
		<li>How many packets are steered into a certain SR path ?</li>
		<li>Which SR Policy or candidate path or segment list this SR path belongs to ?</li>
		</ul>
	<t>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.</t>

    <section numbered="true" toc="default">
      <name>SR-MPLS Path Identification</name>
	  <t>In SR-MPLS<xref target="RFC8660"></xref>, a segment is encoded as an MPLS label. For MPLS label stack information collection, IPFIX IE mplsLabelStackSection(elementID:316)<xref target="RFC5477"></xref> 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 from 70 to 79)<xref target="RFC5102"></xref> provide mechanism to carry the individual MPLS label information in the IPFIX message.</t>
	  <t>But the above IEs are not sufficient for SR-MPLS path identification:</t>
	  <ul spacing="normal">
		<li>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.</li>
		<li>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.</li>
<li>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.</li>
		</ul>
	 </section>

    <section numbered="true" toc="default">
      <name>SRv6 Path Identification</name>
<t><xref target="RFC9487"></xref> 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 <xref target="RFC9487"></xref>, srhSegmentIPv6BasicList (elementID:496) and srhSegmentIPv6ListSection (elementID:497), both encoding the Segment List in the SRH starting from Segment List[0].</t>	  

<t>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:</t>
		<ul spacing="normal">
		<li>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.</li>	
		<li>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 <xref target="RFC8754"></xref> where the first SID is not present in the SRH.</li>
		<li>When the srhSegmentIPv6BasicList or srhSegmentIPv6ListSection contains compressed-SID containers<xref target="I-D.ietf-spring-srv6-srh-compression"></xref>, additional information and processing procedures are required to decode compressed-SID containers as described in <xref target="RFC9487"></xref> section 6.2 to obtain the original segment list information before compression.</li>
		</ul>
	 </section>		
		
		
    <section numbered="true" toc="default">
      <name>SR Path Segment</name>
<t>Path Segment is a type of Segment Routing (SR) segment, and a Path Segment Identifier (PSID) is used to identify an SR path.</t>
<t>For SR-MPLS, as specified in <xref target="RFC9545" format="default"></xref>, 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.</t>
<t>PSID for SRv6 networks is defined in <xref target="I-D.ietf-spring-srv6-path-segment"></xref>. In SRH, the PSID appears as the last entry in the segment list.</t>

<t>This document introduces new IPFIX Information Elements to identify the PSIDs for SR-MPLS and SRv6 paths identification.</t>
	 </section>	 
	  </section>

<section numbered="true" toc="default">
        <name>Terminology</name>
		<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" format="default"></xref> <xref target="RFC8174" format="default"></xref> 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" format="default"></xref>, <xref target="RFC8402" format="default"></xref>, <xref target="RFC8754" format="default"></xref>, <xref target="RFC9545" format="default"></xref> and <xref target="I-D.ietf-spring-srv6-srh-compression"></xref>.</t>
		<t>The following terms are used as defined in <xref target="RFC7011" format="default"></xref>:</t>	
		<ul spacing="normal">
		<li>IPFIX</li>
		<li>IPFIX Information Elements</li>
		<li>Metering Process</li>
		<li>Template Record</li>
		<li>Data Record</li>
		<li>Collector</li>		
		</ul>
		<t>The following terms are used as defined in <xref target="RFC8402" format="default"></xref>:</t>	
		<ul spacing="normal">
		<li>Segment Routing (SR)</li>
		<li>Segment List</li>
		<li>SRv6</li>	
		</ul>
		<t>The following terms are used as defined in <xref target="RFC8754" format="default"></xref>:</t>	
		<ul spacing="normal">
		<li>SRH</li>
		<li>Last Entry</li>
		</ul>
		<t>The following terms are used as defined in <xref target="RFC9545" format="default"></xref> and <xref target="I-D.ietf-spring-srv6-path-segment"></xref>:</t>	
		<ul spacing="normal">
		<li>PSID: Path Segment Identifier</li>
		</ul>		
      </section>

<section numbered="true" toc="default">
	<name>PSID in IPFIX</name>	
	
<section numbered="true" toc="default" anchor="section3.1" >
<name>SR-MPLS PSID in IPFIX</name>
		<t>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.</t>
		<dl newline="false" indent="3" spacing="normal" >
          <dt>Name:</dt>
          <dd>
            <t>psidMpls</t>
          </dd>
          <dt>ElementID:</dt>
          <dd >
            <t>TBD1</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t indent="0">The 24-bit field carrying the Label, Exp, and S of the MPLS label stack entry that contains an SR-MPLS PSID.</t> 
          </dd>
          <dt>Abstract Data Type:</dt>
          <dd>
            <t indent="0" >octetArray</t>
          </dd>
          <dt>Data Type Semantics:</dt>
          <dd >
            <t indent="0">identifier</t>
          </dd>
          <dt>Additional Information:</dt>
          <dd>
            <t indent="0">Specified in <xref target="RFC9545" format="default"></xref>.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t indent="0" >This document.</t>
          </dd>
        </dl>
</section>
<section numbered="true" toc="default" anchor="section3.2">
	<name>SRv6 PSID in IPFIX</name>
		<t>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.</t>
		<dl newline="false" indent="3" spacing="normal" >
          <dt>Name:</dt>
          <dd>
            <t>srhPsidIPv6</t>
          </dd>
          <dt>ElementID:</dt>
          <dd >
            <t>TBD2</t>
          </dd>
          <dt>Description:</dt>
          <dd>
            <t indent="0">The 128-bit IPv6 address that represents an SRv6 PSID.</t> 
          </dd>
          <dt>Abstract Data Type:</dt>
          <dd>
            <t indent="0" >ipv6Address</t>
          </dd>
          <dt>Data Type Semantics:</dt>
          <dd >
            <t indent="0">default</t>
          </dd>
          <dt>Additional Information:</dt>
          <dd>
            <t indent="0">Specified in Section 3 of <xref target="I-D.ietf-spring-srv6-path-segment"></xref>.</t>
          </dd>
          <dt>Reference:</dt>
          <dd>
            <t indent="0" >This document.</t>
          </dd>
        </dl>
		
		<t>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.</t>
		</section>
<section numbered="true" toc="default">
	<name>PSID Usecases</name>
	<t>Network Observability, as described in <xref target="I-D.ietf-nmop-terminology"></xref>, 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.</t>
<t>PSID benefits the SR IPFIX flow visibility for Network Observability. As described in <xref target="RFC9545" format="default"></xref> section 3 and <xref target="I-D.ietf-spring-srv6-path-segment"></xref> 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.
</t>
	</section>	

</section>	
	
<section numbered="true" toc="default">
	<name>Operational Considerations</name>
<section numbered="true" toc="default">
	<name>Operational Considerations for psidMpls</name>
	<t>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.</t>
<t>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.
</t>
</section>	
<section numbered="true" toc="default">
	<name>Operational Considerations for srhPsidIPv6</name>
	<t>As specified in <xref target="I-D.ietf-spring-srv6-path-segment"></xref>, 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.
</t>
	<t>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.
</t>

	<t>As in <xref target="I-D.ietf-spring-srv6-path-segment"></xref> section 3, the PSID allocation depends on the use cases, including:</t>
	<ul spacing="normal">
		<li>each segment list may have its own PSID with different value;</li>
		<li>the same PSID may be used for some or all the segment list under a Candidate path;</li>
		<li>the same PSID may be used for some or all Candidate Path within an SRv6 policy.</li>	
	</ul>		
	<t>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.</t>
	</section>

</section>


<section numbered="true" toc="default">
	<name>Security Considerations</name>
		<t>There are no additional security considerations regarding allocation of these new IPFIX IEs compared to <xref target="RFC7012" format="default"></xref>.</t>
		<t>Other security considerations for SR-MPLS PSID in <xref target="RFC9545" format="default"></xref> and for SRv6 PSID described in <xref target="I-D.ietf-spring-srv6-path-segment"></xref> apply to this document.</t>
</section>	

<section numbered="true" toc="default">
	<name>IANA Considerations</name>
		<t>This document requests IANA to create new IEs under the "IPFIX Information Elements" registry <xref target="RFC7012" format="default"></xref> available at <xref target="IANA-IPFIX" format="default" sectionFormat="of" derivedContent="IANA-IPFIX"/>.</t>
		
		<table anchor="iana-psid">
		<name>IPFIX Information Elements Registry</name>
		<thead>
		<tr>
		<td>Element ID</td><td>Name</td><td>Reference</td>
		</tr>
		</thead>
		<tbody>
		<tr>
		<td>TBD1</td><td>psidMpls</td><td><xref target="section3.1"/></td>
		</tr>
		</tbody>
		<tbody>
		<tr>
		<td>TBD2</td><td>srhPsidIPv6</td><td><xref target="section3.2"/></td>
		</tr>
		</tbody>
	</table>
		
		
		

	</section>


<section numbered="true" toc="default">
	<name>Acknowledgement</name>
    <t>Thanks to Thomas Graf for his detailed review and comments. Thanks to Cheng Li and Chongfeng Xie for their helpful comments and suggestions.</t>
</section>	
	
  </middle>
  <!--  *****BACK MATTER ***** -->

 <back>

   <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

		<?rfc include="reference.RFC.2119.xml"?>
		<?rfc include="reference.RFC.8174.xml"?>
	  	<?rfc include='reference.I-D.ietf-spring-srv6-path-segment.xml'?>			
		<?rfc include="reference.RFC.7012.xml"?>
		<?rfc include="reference.RFC.8754.xml"?>
 		<?rfc include="reference.RFC.8402.xml"?>
		<?rfc include="reference.RFC.7011.xml"?> 
		<reference anchor="IANA-IPFIX" target="https://www.iana.org/assignments/ipfix" quoteTitle="true" derivedAnchor="IANA-IPFIX">
          <front>
            <title>IP Flow Information Export (IPFIX) Entities</title>
            <author>
              <organization showOnFrontPage="true">IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
	  
      </references>
      <references>
        <name>Informative References</name>
		<?rfc include="reference.RFC.9487.xml"?>
		<?rfc include="reference.RFC.9545.xml"?>
		<?rfc include="reference.RFC.5102.xml"?>
		<?rfc include="reference.RFC.8660.xml"?>
		<?rfc include="reference.RFC.5477.xml"?>		
	    <?rfc include='reference.I-D.ietf-spring-srv6-srh-compression.xml'?>
	    <?rfc include='reference.I-D.ietf-nmop-terminology.xml'?>	
      </references>
    </references>


 </back>
</rfc>
