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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<!-- Extra statement used by XSLT processors to control the output style. -->

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="exp" submissionType="independent" ipr="trust200902" docName="draft-fz-spring-srv6-alt-mark-17" >

    <!-- Try to enforce the ID-nits conventions and DTD validity -->
    <?rfc strict="yes" ?>

    <!-- Items used when reviewing the document -->
    <?rfc comments="no" ?>  <!-- Controls display of <cref> elements -->
    <?rfc inline="no" ?>    <!-- When no, put comments at end in comments section,
                                 otherwise, put inline -->
    <?rfc editing="no" ?>   <!-- When yes, insert editing marks: editing marks consist of a
                                 string such as <29> printed in the blank line at the
                                 beginning of each paragraph of text. -->

    <!-- Create Table of Contents (ToC) and set some options for it.
         Note the ToC may be omitted for very short documents,but idnits insists on a ToC
         if the document has more than 15 pages. -->
   <?rfc toc="yes"?>
   <?rfc tocompact="yes"?> <!-- If "yes" eliminates blank lines before main section entries. -->
   <?rfc tocdepth="3"?>    <!-- Sets the number of levels of sections/subsections... in ToC -->

    <!-- Choose the options for the references.
         Some like symbolic tags in the references (and citations) and others prefer
         numbers. The RFC Editor always uses symbolic tags.
         The tags used are the anchor attributes of the references. -->
    <?rfc symrefs="yes"?>
    <?rfc sortrefs="yes" ?> <!-- If "yes", causes the references to be sorted in order of tags.
                                 This doesn't have any effect unless symrefs is "yes" also. -->

    <!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
         main section on a new page but does not omit the blank lines between list items.
         If subcompact is also "yes" the blank lines between list items are also omitted. -->
    <?rfc compact="yes" ?>
    <?rfc subcompact="no" ?>
    <!-- end of list of popular I-D processing instructions -->

    <!-- ***** FRONT MATTER ***** --> number="9947" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">

<front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 42 characters -->
    <title abbrev="SRv6 AMM">Application of the Alternate Marking Alternate-Marking Method to the Segment Routing Header</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <seriesInfo name="RFC" value="9947"/>
    <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Viale Martesana, 12</street>
          <city>Vimodrone (Milan)</city>

          <region></region>
          <code>20055</code>
          <country>Italy</country>
        </postal>
        <email>giuseppe.fioccola@huawei.com</email>
      </address>
    </author>
    <author fullname="Tianran Zhou" initials="T." surname="Zhou">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>156 Beiqing Rd.</street>
          <city>Beijing</city>

          <region></region>
          <code>100095</code>
          <country>China</country>
        </postal>
        <email>zhoutianran@huawei.com</email>
      </address>
    </author>
    <author fullname="Gyan S. Mishra" initials="G." surname="Mishra">
      <organization>Verizon Inc.</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
    <author fullname="Xuewei Wang" initials="X." surname="Wang">
      <organization>Ruijie</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>
        <email>wangxuewei1@ruijie.com.cn</email>
      </address>
    </author>
    <author fullname="Geng Zhang" initials="G." surname="Zhang">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>
        <email>zhanggeng@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
      <organization></organization>
      <organization/>
      <address>
        <postal>
          <street></street>

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>
        <email>mauro.cociglio@outlook.com</email>
      </address>
    </author>
    <date year="2025"/> <!-- month="March" is no longer necessary
                                           note also, day="30" is optional -->
    <!-- WARNING: If the month and year are the current ones, xml2rfc will fill in the day for
         you. If only the year is specified, xml2rfc will fill in the current day and month
         irrespective of the day.  This silliness should be fixed in v1.31. -->

    <!-- Meta-data Declarations -->

    <!-- Notice the use of &amp; as an escape for & which would otherwise
         start an entity declaration, whereas we want a literal &. -->

    <area></area>

    <!-- WG name at the upperleft corner of the doc,
         IETF fine for individual submissions.  You can also
         omit this element in which case in defaults to "Network Working Group" -
         a hangover from the ancient history of the IETF! -->

    <workgroup></workgroup>

    <!-- The DTD allows multiple area and workgroup elements but only the first one has any
         effect on output.  -->
    <!-- You can add <keyword/> elements here.  They will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff output. --> year="2026" month="March"/>

<keyword>SRH</keyword>
<keyword>TLV</keyword>
<keyword>Extension</keyword>
<keyword>Header</keyword>
<keyword>Option</keyword>
<keyword>Performance</keyword>
<keyword>Measurement</keyword>
<keyword>Monitoring</keyword>
<keyword>Passive</keyword>
<keyword>Hybrid</keyword>
<keyword>Loss</keyword>
<keyword>Delay</keyword>
<keyword>Delay Variation</keyword>
<keyword>Multipoint</keyword>
<keyword>Cluster</keyword>
<keyword>Closed-Loop</keyword>

    <abstract>
      <t>This document describes an alternative experimental approach for the application of
		the Alternate-Marking Method to SRv6. Segment Routing for IPv6 (SRv6). It uses an experimental TLV in the Segment Routing Header,
		and thus Header (SRH);
		thus, participation in this experiment should be between coordinating parties in a controlled domain.
		This approach has potential scaling and simplification benefits over the technique
		described in RFC 9343 9343, and the scope of the experiment is to determine whether
		those are significant and attractive to the community.</t>
      <t>This protocol extension has been developed outside the IETF as an
      alternative to the IETF&apos;s standards track IETF's Standards Track specification RFC 9343 and it
      does not have IETF consensus. It is published here to guide experimental implementation,
      implementation and ensure interoperability among implementations to
      better determine the value of this approach.  Researchers are invited to
      submit their evaluations of this work to the RFC Independent Submissions
      Editor for consideration as independent submissions or to the IETF SPRING working group Working Group as Internet-Drafts.</t>
    </abstract>

  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

      <t><xref target="RFC9341"></xref> target="RFC9341" format="default"/> and <xref target="RFC9342"></xref> target="RFC9342" format="default"/>
       describe a passive performance measurement method, which can be used to measure packet loss,
       latency
       latency, and jitter on live traffic. Since this method is based on marking consecutive
       batches of packets, the method is often referred as the Alternate Marking Method.</t> "Alternate-Marking Method".</t>
      <t>The Alternate Marking Alternate-Marking Method requires a marking field so that packet flows
       can be distinguished and identified. <xref target="RFC9343"/> target="RFC9343" format="default"/> defines the standard for how
	   the marking field can be encoded in a new TLV in either Hop-by-hop Hop-by-Hop or Destination Options Headers
	   of IPv6 packets in order to achieve Alternate Marking. The This mechanism to carry is equally
	   applicable to Segment Routing for IPv6 (SRv6) networks <xref target="RFC8402"/>.</t> target="RFC8402" format="default"/>.</t>
      <t>This document describes an alternative experimental approach that encodes the
	   marking field in a new TLV carried in the Segment Routing Header (SRH) <xref target="RFC8754"/> target="RFC8754" format="default"/>
	   of an SRv6 packet. This approach is applicable only to SRv6 deployments. It is intended to capitalize on the
	   assumption that Segment Routing (SR) nodes are supposed to support fast parsing and processing
	   of the SRH, while the SR nodes may not handle properly handle Destination Options, as discussed in
	   <xref target="RFC9098"/>, target="RFC9098" format="default"/> and <xref target="I-D.ietf-6man-eh-limits"/>. target="I-D.ietf-6man-eh-limits" format="default"/>.
	   The experiment is to determine whether or not there are significant and attractive advantages
	   to the community: if there are, the work may be brought back for IETF consideration.</t>

      <t>This protocol extension has been developed outside the IETF as an
      alternative to the IETF&apos;s standards track IETF's Standards Track specification <xref target="RFC9343"/> and
      target="RFC9343" format="default"/>; it does not have IETF consensus. It
      is published here to guide experimental implementation, implementation and ensure
      interoperability among implementations to better determine the value of
      this approach.  As also highlighted in <xref target="I-D.bonica-gendispatch-exp"/>,
      target="I-D.bonica-gendispatch-exp" format="default"/>, when two
      protocol extensions are proposed to solve a single problem, an
      experiment can be initiated to gather operational experience and this
      "determine which, if either, of the protocols should be progressed to
      the standards track."  This is the purpose of this document.  See <xref target="experimentation"/>
      target="experimentation" format="default"/> for more details about the experimentation.</t>
      experiment.</t>

      <section anchor="observations" title="Observations numbered="true" toc="default">
        <name>Observations on RFC 9343"> 9343</name>
        <t>Like any other IPv6 use case, Hop-by-Hop and Destination Options can also be used when the SRH is present.
	    As specified in <xref target="RFC8200"/>, target="RFC8200" format="default"/>, the Hop-by-Hop Options Header is used to carry optional information
	    that needs to be examined at every hop along the path, while the Destination Options Header is used to carry optional information
	    that needs to be examined only by the packet's destination node(s).</t>
        <t>When a Routing Header exists, because the SRH is a Routing Header,
        Destination Options present in the IPv6 packet before the SRH header
        are processed by the destination indicated in the SRH&apos;s SRH's route list.  As
        specified in <xref target="RFC8754"/>, target="RFC8754" format="default"/>, SR segment
        endpoint nodes process the local SID Segment Identifier (SID)
        corresponding to the packet destination address. Then, the destination
        address is updated according to the segment list.  The SRH TLV
        provides metadata for segment processing, while processing the SID, if
        the node is locally configured to do so.  Both the Destination Options
        Header before the SRH and the SRH TLV are processed at the node being
        indicated in the destination address field of the IPv6 header.</t>

        <t>The distinction between the alternatives is most notable for SRv6
        packets that traverse a network where the paths between sequential
        segment end points endpoints include multiple hops. If the Hop-by-Hop Option is
        used, then every hop along the path will process the AltMark data. If
        the Destination Option positioned before the SRH is used, or the SRH
        AltMark TLV is used, then only the segment end points endpoints will process the
        AltMark data.</t> data, unless the intermediate node has a different priority rule.</t>
        <t>Both <xref target="RFC9343"/> target="RFC9343" format="default"/> and the approach
        specified in this document can co-exist. coexist. Indeed, this document does
        not change or invalidate any procedures defined in <xref target="RFC9343"/>.
        target="RFC9343" format="default"/>. However, deployment issues may
        arise, as further discussed below.</t>
        <t>The rest of this document is structured as follows: <xref target="SRv6AltMark"/> follows:</t>
	<ul>
	  <li><xref target="SRv6AltMark" format="default"/> covers the application of the Alternate Marking
        Alternate-Marking Method to SRv6,
		<xref target="AltMarkTLV"/> SRv6,</li>
	<li><xref target="AltMarkTLV" format="default"/> specifies the AltMark SRH TLV to carry the base
        data fields (<xref target="base"/>) target="base" format="default"/>) and the extended
        data fields (<xref target="extended"/>), <xref target="Use"/> target="extended" format="default"/>),</li>
	<li><xref target="Use" format="default"/> discusses the use of the AltMark TLV, and <xref target="experimentation"/>
        and</li>
	<li><xref target="experimentation" format="default"/> describes the
        experiment and the objectives of the experimentation (<xref target="objective"/>).</t>
        target="objective" format="default"/>).</li>
	</ul>
      </section>
      <section title="Requirements Language">
            <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
             "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
             "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
      </section>
    </section>

    <section anchor="SRv6AltMark" title="Application numbered="true" toc="default">
      <name>Application of the Alternate Marking Alternate-Marking Method to SRv6"> SRv6</name>
      <t>SRv6 leverages the IPv6 SRH, that which can embed TLVs to provide metadata
      for segment processing, as described in <xref target="RFC8754"/>. target="RFC8754"
      format="default"/>.  This document defines the SRH AltMark TLV to carry Alternate Marking
      Alternate-Marking data fields for use in SRv6 networks networks, and it is an
      alternative to the method described in <xref target="RFC9343"/>. target="RFC9343" format="default"/>. <xref target="RFC9343"/>
      target="RFC9343" format="default"/> defines how the Alternate Marking Alternate-Marking
      Method can be carried in the Option Headers
	  (Hop-by-hop (Hop-by-Hop or Destination)
      of an IPv6 packet. The AltMark data fields format defined in <xref target="RFC9343"/>
      target="RFC9343" format="default"/> is the basis of the AltMark SRH TLV
      introduced in <xref target="AltMarkTLV"/>.</t> target="AltMarkTLV" format="default"/>.</t>
      <t>In addition to the base data fields of <xref target="RFC9343"></xref>, it is also allowed target="RFC9343"
      format="default"/>, the insertion of optional
   extended data fields
	  which that are not present in <xref target="RFC9343"></xref>. target="RFC9343"/> is also allowed.
These extended data fields can support metadata for
      additional telemetry requirements, as further described below.</t>
      <section anchor="control" title="Controlled Domain"> numbered="true" toc="default">

        <name>Controlled Domain</name>
        <t><xref target="RFC8799"/> target="RFC8799" format="default"/> introduces the concept of specific limited domain solutions and
        notes the application of the Alternate Marking Alternate-Marking Method as an example.</t>
        <t>Despite the flexibility of IPv6, when innovative applications are proposed proposed, they are often
        applied within controlled domains to help constrain the domain-wide policies, options supported,
        the style of network management, and security requirements. This is also the case for applying
        the application
        of the Alternate Marking Alternate-Marking Method to SRv6.</t>
        <t>Therefore, the experimentation experiment of applying the Alternate Marking Alternate-Marking Method
        to SRv6 MUST <bcp14>MUST</bcp14> only be deployed only within a controlled
        domain.  For SRv6, the controlled domain corresponds to an SR domain,
        as defined in <xref target="RFC8402"/>. target="RFC8402" format="default"/>.  The
        Alternate-Marking measurement domain overlaps with the controlled
        domain.</t>

        <t>The use of a controlled domain is also appropriate for the
        deployment of an experimental protocol extension.  Carefully bounding
        the domain reduces the risk of the experiment leaking out and clashing
        with other experiments of or causing unforeseen consequences in wider
        deployments.</t>
      </section>
    </section>
    <section anchor="AltMarkTLV" title="Definition numbered="true" toc="default">
      <name>Definition of the SRH AltMark TLV"> TLV</name>
      <t>The AltMark SRH TLV is defined to carry the data fields associated with the Alternate Marking Alternate-Marking Method.
        The TLV has some initial fields that are always present, present and further extension fields that are
        present when Enhanced Alternate Marking is in use.</t>
      <t><xref target="AltMarkFig"/> target="AltMarkFig" format="default"/> shows the format of the AltMark TLV.</t>
      <figure anchor="AltMarkFig">
          <name>AltMark:
        <name>The AltMark SRH TLV for alternate marking</name> Alternate Marking</name>
        <artwork align="center">
          <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRH TLV Type  |  SRH TLV Len  |         Reserved              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              FlowMonID                |L|D|  Reserved |  NH   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~              Optional extended data fields (variable)         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ]]>
          </artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
      </figure>
      <t>The fields of this TLV are as follows:

          <list style="symbols">
            <t>SRH follows:</t>

      <dl spacing="normal" newline="false">
        <dt>SRH TLV Type: 8 bit Type:</dt><dd>The 8-bit identifier of the Alternate Marking
        Alternate-Marking SRH TLV. The value for this field is taken from the
        range 124-126. It is an Experimental code point that indicates a TLV
        that does not change en route. Experimentation Deployment of this document must
        coordinate the value used by all implementations participating in the
        experiment.  Therefore, experiments should carefully consider any
        other implementations running in the controlled domain to avoid
        clashes with other SRH TLVs.</t>

            <t>SRH TLVs.</dd>
        <dt>SRH TLV Len: The Len:</dt><dd>The length of the Data Fields of this TLV in
        bytes. This is set to 6 when Enhanced Alternate Marking is not in use.</t>

            <t>Reserved: Reserved
        use.</dd>
        <dt>Reserved:</dt><dd>Reserved for future use. These bits MUST
        <bcp14>MUST</bcp14> be set to zero on transmission and ignored on receipt.</t>

            <t>FlowMonID:
        receipt.</dd>
        <dt>FlowMonID:</dt><dd>The Flow Monitoring Identification field, 20 bits unsigned integer. field. It is a 20-bit
        unsigned integer as defined in <xref target="RFC9343"/>.</t>

            <t>L: target="RFC9343"
        format="default"/>.</dd>
        <dt>L:</dt><dd>The Loss flag, as defined in <xref target="RFC9343"/>.</t>

            <t>D: target="RFC9343"
        format="default"/>.</dd>
        <dt>D:</dt><dd>The Delay flag, as defined in <xref target="RFC9343"/>.</t>

            <t>NH: The NH (NextHeader) field target="RFC9343"
        format="default"/>.</dd>
        <dt>NH:</dt><dd><t>The NextHeader field. It is used to indicate extended
        data fields are present to support Enhanced Alternate Marking as follows:
              <list>
        follows:</t>
          <ul spacing="normal">
            <li>
              <t>NextHeader value of 0x0 means that there is no extended data field attached.</t>
            </li>
            <li>
              <t>NextHeader values of 0x1-0x8 are reserved for further usage.</t>
            </li>
            <li>
              <t>NextHeader value of 0x9 indicates the extended data fields are present as
                described in <xref target="extended"/>.</t> target="extended" format="default"/>.</t>
            </li>
            <li>
              <t>NextHeader values of 0xA-0xF are reserved for further usage.</t>
              </list>
            </t>
            </li>
          </ul>
	</dd></dl>
          <t>Optional extended data fields may be present according to the setting of the NH field
            and as described in <xref target="extended"/>.</t>

          </list>
        </t> target="extended" format="default"/>.</t>
      <section anchor="base" title="Base Alternate Marking numbered="true" toc="default">
        <name>Base Alternate-Marking Data Fields"> Fields</name>
        <t>The base AltMark data fields are: the Loss Flag (L), (L) flag, the Delay Flag (D) flag, and the
        Flow Monitoring Identification field (FlowMonID), (FlowMonID) field, as in <xref target="RFC9343"></xref>.</t>
        target="RFC9343" format="default"/>.</t>
        <t>L and D are the marking fields of the Alternate Marking Method Alternate-Marking Method,
        while FlowMonID is used to identify monitored flows and aids the
        optimization of implementation and scaling of the Alternate Marking Alternate-Marking
        Method. Note that, as already highlighted in <xref target="RFC9343"></xref>, target="RFC9343"
        format="default"/>, the FlowMonID is used to identify the monitored
        flow because it is not possible to utilize the Flow Label field of the
        IPv6 Header.</t>
        <t>It is important to note that if the 20 bit 20-bit FlowMonID is set by the domain entry nodes, there is a
            chance of collision even when the values are chosen using a pseudo-random pseudorandom algorithm; therefore therefore, it may be not be
            sufficient to uniquely identify a monitored flow. In such cases cases, the packets need to be tagged with additional
            flow information to allow disambiguation. Such additional tagging can be carried in the extended data fields
            described in <xref target="extended"/>.</t> target="extended" format="default"/>.</t>
      </section>
      <section anchor="extended" title="Optional numbered="true" toc="default">
        <name>Optional Extended Data Fields for Enhanced Alternate Marking"> Marking</name>
        <t>The optional extended data fields to support Enhanced Alternate Marking are illustrated in
            <xref target="extendedFig"/>. target="extendedFig" format="default"/>. They are present when the NH field of the AltMark TLV is set to 0x9.</t>
        <figure anchor="extendedFig" > anchor="extendedFig">
          <name>Optional Extended Data Fields for Enhanced Alternate Marking</name>
          <artwork align="center">
              <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           FlowMonID Ext               |M|F|W|R|  Len  | Rsvd  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           MetaInfo            |      Optional MetaData        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~               Optional MetaData (variable)                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ]]>
             </artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
        </figure>
        <t>The extended data fields are as follows:
             <list style="symbols">

               <t>FlowMonID Ext - 20 bits follows:</t>

	<dl spacing="normal" newline="false">

          <dt>FlowMonID Ext:</dt><dd>20-bit unsigned integer. This is integer used to
          extend the FlowMonID in order to reduce the conflict when random
          allocation is applied. The disambiguation of the FlowMonID field is
          discussed in "IPv6 Application of the Alternate-Marking Method" <xref target="RFC9343">IPv6 AltMark Option</xref>.</t>

               <t>Four bit-flags target="RFC9343" format="default"/>.</dd>
          <dt>Four different bit flags indicate special-purpose usage.
                 <list style="hanging">
                   <t hangText='M bit:'>Measurement usage.</dt><dd><t><br/></t>
            <dl newline="false" spacing="normal">
              <dt>M bit:</dt><dd>Measurement mode. If M=0, it indicates that
              it is for segment-by-segment monitoring. If M=1, it indicates
              that it is for end-to-end monitoring.</t>

                   <t hangText='F bit:'>Fragmentation. monitoring.</dd>
              <dt>F bit:</dt><dd>Fragmentation. If F=1, it indicates that the
              original packet is fragmented, therefore fragmented; therefore, it is necessary to only
              count a single packet, ignoring all the following fragments with
              F set to 1.  Note that F is set to 0 for the first fragment.</t>

                   <t hangText='W bit:'>Flow
              fragment.</dd>
              <dt>W bit:</dt><dd>Flow direction identification. This flag is
              used if backward direction flow monitoring is requested to be
              set up automatically, so that the egress node is instructed to
              setup the backward flow monitoring. If W=1, it indicates that
              the flow direction is forward. If W=0, it indicates that the
              flow direction is backward.</t>

                   <t hangText='R bit:'>Reserved. backward.</dd>
              <dt>R bit:</dt><dd>Reserved. This bit MUST <bcp14>MUST</bcp14> be
              set to zero and ignored on receipt.</t>
                 </list>
               </t>

               <t>Len - Length. receipt.</dd>
            </dl>
          </dd>
          <dt>Len:</dt><dd>Length. Indicates the length of the extended data
          fields in bytes for enhanced alternate
               marking. Enhanced Alternate Marking as a multiple of 4 bytes. It includes all of
          the fields shown in <xref target="extendedFig"/> target="extendedFig" format="default"/>
          including any
               meta data metadata that is present.</t>

               <t>Rsvd - Reserved present.</dd>
          <dt>Rsvd:</dt><dd>Reserved for further use. These bits MUST
          <bcp14>MUST</bcp14> be set to zero on transmission and ignored on receipt.</t>

               <t>MetaInfo - A
          receipt.</dd>
          <dt>MetaInfo:</dt><dd><t>A 16-bit Bitmap to indicate more meta data metadata
          attached in the Optional MetaData field for enhanced functions. More
          than one bit may be set, in which case the additional meta data metadata is
          present in the order that the bits are set. MetaInfo bits are
          numbered from 0 as the most significant bit.  Three bits and
          associated meta data metadata are defined as follows:

                 <list style="hanging">
                   <t hangText='bit 0:'>If follows:</t>
            <dl newline="false" spacing="normal">
              <dt>bit 0:</dt>
              <dd><t>If set to 1, it indicates that a 6 byte 6-byte Timestamp is present
              as shown in <xref target="timestampFig"/>. target="timestampFig" format="default"/>.</t>
                <figure anchor="timestampFig">
                  <name>The Timestamp Extended Data Field</name>
                  <artwork align="center">
                       <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                |    Timestamp(s)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Timestamp(ns)                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ]]>
                       </artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
                </figure>

                   This
                <t>This Timestamp can be filled by the encapsulation node, node
                and is taken all the way to the decapsulation node so that all
                the intermediate nodes can compare it against their local time,
                time and measure the one way one-way delay. The
                   timestamp Timestamp consists of
                two fields:
                     <list>
                       <t>Timestamp(s) is a 16 bit fields:</t>
                <dl newline="false" spacing="normal">
                  <dt>Timestamp(s):</dt><dd>A 16-bit integer that carries the number of seconds.</t>
                       <t>Timestamp(ns) is a 32 bit seconds.</dd>
                  <dt>Timestamp(ns):</dt><dd>A 32-bit integer that carries the number of nanoseconds.</t>
                     </list>
				   Note nanoseconds.</dd>
                </dl>
                <t>Note that the timestamp Timestamp data field enables all the
                intermediate nodes to measure the one way one-way delay.  It can be
                correlated with the implementation of <xref target="I-D.ietf-opsawg-ipfix-on-path-telemetry"/>
                target="I-D.ietf-opsawg-ipfix-on-path-telemetry"
                format="default"/> and <xref target="I-D.ietf-ippm-on-path-telemetry-yang"/>.
                target="I-D.ietf-ippm-on-path-telemetry-yang"
                format="default"/>.  <xref target="I-D.ietf-opsawg-ipfix-on-path-telemetry"/>
                target="I-D.ietf-opsawg-ipfix-on-path-telemetry"
                format="default"/> introduces new IP Flow Information Export
                (IPFIX) information elements to expose the On-Path Telemetry
                measured delay, similarly, delay. Similarly, <xref target="I-D.ietf-ippm-on-path-telemetry-yang"/>
                target="I-D.ietf-ippm-on-path-telemetry-yang"
                format="default"/> defines a YANG data model for monitoring
                On-Path Telemetry data, including the path delay.
                   </t>

                   <t hangText='bit 1:'>If delay.</t>
              </dd>
              <dt>bit 1:</dt>
              <dd><t>If set to 1, it indicates the control information to set
              up the backward direction flow monitoring based on the trigger
              packet presence as shown in <xref target="controlFig"/>. target="controlFig"
              format="default"/>.</t>

                <figure anchor="controlFig">
                  <name>Control Information for Backward Direction Flow Monitoring</name>
                  <artwork align="center">
                       <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  DIP Mask     |  SIP Mask     |P|I|O|V|S|T|    Period         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ]]>
                       </artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
                </figure>

                   The
                <t>The control information includes several fields and flags
                to match in order to set up the backward direction:
                     <list>

                       <t>DIP Mask: The direction:</t>
                <dl newline="false" spacing="normal">
                  <dt>DIP Mask:</dt><dd>The length of the destination IP prefix used to match the flow.</t>

                       <t>SIP Mask: The flow.</dd>
                  <dt>SIP Mask:</dt><dd>The length of the source IP prefix used to match the flow.</t>

                       <t>P bit: If flow.</dd>
                  <dt>P bit:</dt><dd>If set to 1, it indicates to match the flow using the protocol identifier in the trigger packet.</t>

                       <t>I bit: If packet.</dd>
                  <dt>I bit:</dt><dd>If set to 1, it indicates to match the source port.</t>

                       <t>O bit: If port.</dd>
                  <dt>O bit:</dt><dd>If set to 1, it indicates to match the destination port.</t>

                       <t>V bit: If port.</dd>
                  <dt>V bit:</dt><dd>If set to 1, the node will automatically
                  set up reverse direction monitoring, monitoring and allocate a FlowMonID.</t>

                       <t>S bit: If
                  FlowMonID.</dd>
                  <dt>S bit:</dt><dd>If set to 1, it indicates to match the DSCP.</t>

                       <t>T bit: Used Differentiated Services Code Point (DSCP).</dd>
                  <dt>T bit:</dt><dd>Used to control the scope of tunnel
                  measurement. T=1 means measure between Network-to-Network
                  Interfaces (i.e., NNI to NNI).  T=0 means measure between
                  User-to-Network Interfaces (i.e., UNI to UNI).</t>

                       <t>Period: Indicates UNI).</dd>
                  <dt>Period:</dt><dd>Indicates the alternate marking Alternate-Marking period counted in seconds.</t>
                     </list>
                   </t>

                   <t hangText='bit 2:'>If seconds.</dd>
                </dl>
              </dd>
              <dt>bit 2:</dt>
              <dd>
                <t>If set to 1, it indicates that a 4 byte sequence number 4-byte Sequence Number is
                present as shown in <xref target="seqnoFig"/>. target="seqnoFig"
                format="default"/>.</t>

                <figure anchor="seqnoFig">
                  <name>Sequence Number Data Field</name>
                  <artwork align="center">
                       <![CDATA[ align="center" name="" type="" alt=""><![CDATA[
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sequence Number                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       ]]>
                       </artwork>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
                </figure>

                     The
                <t>The unique Sequence Number can be used to detect the
                out-of-order packets, in addition to enabling packet loss
                measurement. Moreover, the Sequence Number can be used
                together with the latency measurement, measurement to access
                     per packet timestamps.</t>
                 </list>
               </t>

             </list>
           </t> per-packet
                Timestamps.</t>
              </dd>
            </dl>
	  </dd>
	  </dl>

      </section>
    </section>
    <section anchor="Use" title="Use numbered="true" toc="default">
      <name>Use of the SRH AltMark TLV"> TLV</name>
      <t>Since the measurement domain is congruent with the SR controlled SR-controlled domain, the procedure
	  for AltMark data encapsulation in the SRv6 SRH is summarized as follows:
        <list style="symbols">
      </t>
      <ul spacing="normal">
        <li>
          <t>Ingress SR Node: As part of the SRH encapsulation, the Ingress SR
          Node of an SR domain or an SR Policy <xref target="RFC9256"/> target="RFC9256"
          format="default"/> that supports the mechanisms defined in this
          document and that wishes to perform the Alternate Marking Alternate-Marking Method
          adds the AltMark TLV in the SRH of the data packets.</t>
        </li>
        <li>
          <t>Intermediate SR Node: The Intermediate SR Node is any node
          receiving an IPv6 packet where the destination address of that
          packet is a local Segment Identifier (SID). If an Intermediate SR
          Node is not capable of processing the AltMark TLV, it simply ignores it
          according to the processing rules of <xref target="RFC8754"/>. target="RFC8754"
          format="default"/>. If an Intermediate SR Node is capable of
          processing the AltMark TLV, it checks if the SRH AltMark TLV is present
          in the packet and processes it.</t>
        </li>
        <li>
          <t>Egress SR Node: The Egress SR Node is the last node in the
          segment list of the SRH. The processing of AltMark TLV at the Egress
          SR Node is the same as the processing of AltMark TLV at the
          Intermediate SR Nodes.</t>
        </list>
       </t>
        </li>
      </ul>
      <t>The use of the AltMark TLV may be combined with the network
      programming capability of SRv6 (<xref target="RFC8986"/>). <xref target="RFC8986"
      format="default"/>.  Specifically, the ability for an SRv6 endpoint to
      determine whether to process or ignore some specific SRH TLVs (such as
      the AltMark TLV) may be based on the SID function associated with the
      SID advertised by an Intermediate or Egress SR Node and used in the
      Destination Address field of the SRv6 packet. When a packet is addressed
      to a SID which that does not support the
       Alternate Marking Alternate-Marking functionality, the
      receiving node does not have to look for or process the SRH AltMark TLV
      and can simply ignore it. This also enables collection of Alternate Marking Alternate-Marking data only from the supporting segment endpoints.</t>
      <section anchor="compatibility" title="Compatibility"> numbered="true" toc="default">
        <name>Compatibility</name>
        <t>As highlighted in <xref target="observations"/>, target="observations" format="default"/>,
        the use of the Destination Option to carry the AltMark data preceding
        the SRH is equivalent to the SRH AltMark TLV. Therefore, it is
        important to analyze what happens when both the SRH AltMArk AltMark TLV and
        the Destination Option are present, and how that would impact
        processing and complexity.</t>
        <t>It is worth mentioning that the SRH AltMark TLV and the the
        Destination Option carrying AltMark data can coexist without problems.
        If both are present, the only issue could be the duplication of information
        information, but this will not affect in any way the device and the
        network services.
	  The security requirement of controlled domain applies to both     Both this document and <xref target="RFC9343"/>, and it also target="RFC9343"/> require a controlled domain for
   security purposes, which confines this duplication to a
   single service provider networks.
	  However, duplication network. Duplication of the same
   information in different places should be avoided avoided, and it is recommended to only analyze analyzing
   the use of only the SRH AltMark TLV
	  for the experimentation.</t> is recommended as part of
   this experiment.</t>
      </section>
    </section>
    <section anchor="experimentation" title="Experimentation Overview"> numbered="true" toc="default">
      <name>Experimentation Overview</name>
      <t>The protocol extension, extension described in this document, document is built on existing technology using an Experimental code point.
	  Experimentation of this document
   Experiment participants must use a code point chosen from the Experimental range, as noted in <xref target="AltMarkTLV"/>, target="AltMarkTLV" format="default"/>,
	  and should make it possible for the operator to configure the value used in a deployment such that it is possible to conduct
	  multiple non-conflicting experiments within the same network.</t>
      <t>This experiment aims to determine whether or not the use of the SRH AltMark TLV brings advantages,
	  in particular particular, in consideration of implementations that cannot support multiple IPv6 extension headers in the same packet,
	  or which do not support Destination Options Header processing, or which process the Destination Options Header on the slow path.</t>
      <t>This experiment also needs to determine whether the proposed protocol
      extensions achieve the desired function and can be supported in the
      presence of normal SRv6 processing. In particular, the experiment needs
      to verify the ability to support SR network programming, SID function control
      control, and the support or non-support of the AltMark TLV.</t>
      <t>It is anticipated that this experiment will be contained within a
      single service provider network in keeping with the constraints of an SR Domain,
      domain, and also in keeping with the limits in sharing performance
      monitoring data collected on the path of packets in the network. The
      scope of the experimental deployment may depend on the availability of
      implementations and the willingness of operators to deploy it on live
      networks.</t>

     <t>The results of this experiment will be collected and shared with the RFC
   Independent Submissions Editor for consideration as independent submission or with the IETF SPRING working group Working Group
   as Internet-Draft, Internet-Drafts to help forward progress the
   discussions that will determine the correct development of Alternate Marking Alternate-Marking Method solutions in SRv6 networks.  It is expected that a first set of initial results
      will be made available within two years of the publication of this
      document as an RFC.</t>
      <section anchor="objective" title="Objective numbered="true" toc="default">
        <name>Objective of the Experiment"> Experiment</name>
        <t>Researchers are invited to evaluate the SRH AltMark TLV against the
        existing approach in <xref target="RFC9343"/>. target="RFC9343" format="default"/>.  There
        are several potential areas of exploration for this experimentation
        that need to be analyzed:<list> analyzed:</t>
        <ul spacing="normal">
          <li>
            <t>Does the use of the SRH AltMark TLV survive across a network
            better or worse than the use of an extension headers usage?</t> header?</t>
          </li>
          <li>
            <t>Does the SRH TLV processing represent a performance improvement or hindrance on the device as compared to the Destination Option?</t>
          </li>
          <li>
            <t>Is the forwarding plane performance impacted across different
            device architecture types when comparing the use of the SRH TLV and
            with the use of Destination Option?</t>
          </li>
          <li>
            <t>How does the use of the extended data fields, introduced in <xref target="extended"/>,
            target="extended" format="default"/>, compare to other on path on-path
            telemetry methods from the point of view of the operators?</t>

		 </list></t>
          </li>
        </ul>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security considerations of SRv6 are discussed in <xref target="RFC8754"/> target="RFC8754" format="default"/> and <xref target="RFC8986"/>, target="RFC8986" format="default"/>,
        and the security considerations of Alternate Marking in general and its application to IPv6
        are discussed in <xref target="RFC9341"/> target="RFC9341" format="default"/> and <xref target="RFC9343"/>.</t> target="RFC9343" format="default"/>.</t>
      <t><xref target="RFC9343"/> target="RFC9343" format="default"/> analyzes different security concerns and related solutions. These aspects are valid and applicable also
        to this document. In particular particular, the fundamental security requirement is that Alternate Marking
        MUST
        <bcp14>MUST</bcp14> only be applied in a limited domain, as also mentioned in <xref target="RFC8799"/> target="RFC8799" format="default"/> and <xref target="control"/>.</t> target="control" format="default"/>.</t>
      <t>Alternate Marking is a feature applied to a trusted domain, where a
      single operator decides on leveraging and configuring Alternate Marking
      according to their needs. Additionally, operators need to properly
      secure the Alternate Marking Alternate-Marking domain to avoid malicious configuration and
      attacks, which could include injecting malicious packets into a
      domain. So Therefore, the implementation of Alternate Marking is applied within a
      controlled domain where the network nodes are locally administered and
      where packets containing the AltMark TLV are prevented from entering or
      leaving the domain. A limited administrative domain provides the network
      administrator with the means to select, monitor monitor, and control the access
      to the network.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document makes has no requests for IANA actions.</t>
    </section>

  </middle>
  <back>
    <displayreference target="I-D.bonica-gendispatch-exp" to="IETF-EXPERIMENTS"/>
    <displayreference target="I-D.ietf-ippm-on-path-telemetry-yang" to="YANG-TELEMETRY"/>
    <displayreference target="I-D.ietf-opsawg-ipfix-on-path-telemetry" to="IPFIX"/>
    <displayreference target="I-D.ietf-6man-eh-limits" to="EH-LIMITS"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9342.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9343.xml"/>
      </references>
      <references>
        <name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8754.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8799.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8986.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9256.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9098.xml"/>
<!-- [I-D.ietf-6man-eh-limits]
draft-ietf-6man-eh-limits-19
IESG State: IESG Evaluation::Revised I-D Needed as of 10/07/25
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-6man-eh-limits.xml"/>
<!-- [I-D.ietf-opsawg-ipfix-on-path-telemetry]
draft-ietf-opsawg-ipfix-on-path-telemetry-23
IESG State:  RFC Ed Queue (AUTH) as of 10/07/25
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-opsawg-ipfix-on-path-telemetry.xml"/>

<!-- [I-D.ietf-ippm-on-path-telemetry-yang]
draft-ietf-ippm-on-path-telemetry-yang-01
IESG State: I-D Exists as of 10/07/25
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ippm-on-path-telemetry-yang.xml"/>

<!-- [I-D.bonica-gendispatch-exp]
draft-bonica-gendispatch-exp-06
IESG State: I-D Exists as of 10/07/25
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.bonica-gendispatch-exp.xml"/>
      </references>
    </references>

    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Eliot Lear, Adrian Farrel, Joel <contact fullname="Eliot Lear"/>,
      <contact fullname="Adrian Farrel"/>, <contact fullname="Joel
      M. Halpern Halpern"/>, and Haoyu Song <contact fullname="Haoyu Song"/> for the precious
      comments and suggestions.</t>
    </section>

    <section title="Contributors"> numbered="false" toc="default">
      <name>Contributors</name>
      <t>The following people provided relevant contributions to this document:</t>

      <t><figure>
          <artwork><![CDATA[
Fabio Bulgarella
Telecom Italia
Email: fabio.bulgarella@guest.telecomitalia.it

Massimo Nilo
Telecom Italia
Email: massimo.nilo@telecomitalia.it

Fabrizio Milan
Telecom Italia
Email: fabrizio.milan@telecomitalia.it

]]></artwork>
        </figure></t>

    <contact fullname="Fabio Bulgarella">
      <organization>Telecom Italia</organization>
      <address>
        <email>fabio.bulgarella@guest.telecomitalia.it</email>
      </address>
    </contact>

    <contact fullname="Massimo Nilo">
      <organization>FiberCop</organization>
      <address>
        <email>massimo.nilo@fibercop.com</email>
      </address>
    </contact>

    <contact fullname="Fabrizio Milan">
      <organization>FiberCop</organization>
      <address>
        <email>fabrizio.milan@fibercop.com</email>
      </address>
    </contact>
    </section>

</middle>

<!--  *****BACK MATTER ***** -->
<back>
    <!-- References split to informative and normative -->
    <references title="Normative References">

       <?rfc include='reference.RFC.2119'?>

       <?rfc include='reference.RFC.8174'?>

       <?rfc include='reference.RFC.8402'?>

       <?rfc include='reference.RFC.9341'?>

       <?rfc include='reference.RFC.9342'?>

       <?rfc include='reference.RFC.9343'?>

    </references>

    <references title="Informative References">
        <!-- A reference written by by an organization not a persoN. -->

       <?rfc include='reference.RFC.8200'?>

       <?rfc include='reference.RFC.8754'?>

       <?rfc include='reference.RFC.8799'?>

       <?rfc include='reference.RFC.8986'?>

       <?rfc include='reference.RFC.9256'?>

       <?rfc include='reference.RFC.9098'?>

       <?rfc include='reference.I-D.ietf-6man-eh-limits'?>

	   <?rfc include='reference.I-D.ietf-opsawg-ipfix-on-path-telemetry'?>

	   <?rfc include='reference.I-D.ietf-ippm-on-path-telemetry-yang'?>

	   <?rfc include='reference.I-D.bonica-gendispatch-exp'?>

    </references>
  </back>
</rfc>