draft-tgraf-opsawg-ipfix-inband-telemetry-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-tgraf-opsawg-ipfix-inband-telemetry-01"
     ipr="trust200902">
  <front>
    <title abbrev="Export of Forwarding Path Delay in IPFIX">Export of
    Forwarding Path Delay in IPFIX</title>

    <author fullname="Thomas Graf" initials="T" surname="Graf">
      <organization>Swisscom</organization>

      <address>
        <postal>
          <street>Binzring 17</street>

          <city>Zurich</city>

          <code>8045</code>

          <country>Switzerland</country>
        </postal>

        <email>thomas.graf@swisscom.com</email>
      </address>
    </author>

    <author fullname="Benoit Claise" initials="B" surname="Claise">
      <organization>Huawei</organization>

      <address>
        <email>benoit.claise@huawei.com</email>
      </address>
    </author>

    <author fullname="Alex Huang Feng" initials="A." surname="Huang Feng">
      <organization>INSA-Lyon</organization>

      <address>
        <postal>
          <street/>

          <city>Lyon</city>

          <region/>

          <code/>

          <country>France</country>
        </postal>

        <phone/>

        <facsimile/>

        <email>alex.huang-feng@insa-lyon.fr</email>

        <uri/>
      </address>
    </author>

    <date day="28" month="July" year="2022"/>

    <abstract>
      <t>This document introduces new IP Flow Information Export (IPFIX)
      information elements to expose the Inband Telemetry measured forwarding
      path delay on the IOAM transit and decapsulation nodes.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t>Network operators want a statistical delay view of their networks.
      They want to understand where in the network, for which customer
      traffic, how much and why delay is being accummlated. In order to answer
      why and where, delay needs to be reported into device and control-plane
      context. In order to understand which customer traffic is affected,
      delay needs to be reported into customer data-plane context. That
      enables network operators to quickly identify when the control-plane
      updates the current path with a different next-hop and therefore the
      forwarding path changes to different nodes and interfaces, how the path
      delay changes for which customer traffic.</t>

      <t>With Inband Telemetry, defined in <xref
      target="I-D.ietf-ippm-ioam-deployment">In-situ OAM</xref>, <xref
      target="I-D.filsfils-spring-path-tracing">Path Tracing</xref> and <xref
      target="I-D.song-opsawg-ifit-framework">In-situ Flow Information
      Telemetry</xref>, the path delay between two endpoints is measured by
      inserting a timestamp in the packet.</t>

      <t>Inband Telemetry can be distinguished between two modes. Passport
      mode, <xref target="RFC9197"/>, where only the last hop in the
      forwarding path of the Inband Telemetry domain exposes all the metrics,
      and postcard mode, <xref
      target="I-D.song-ippm-postcard-based-telemetry"/>, where the metrics are
      also exposed in the transit nodes. In both modes the forwarding path
      exposes performance metrics allowing to determine how much delay has
      been accumulated on which hop.</t>

      <t>This document defines eight new IPFIX Information Elements (IEs),
      exposing the forwarding path delay on IOAM transit and decapsulation
      nodes. Since these IPFIX IEs are performance metrics <xref
      target="RFC8911"/>, they must be registered as registered performance
      metrics <xref target="RFC8911"/> in the <xref
      target="IANA-PERF-METRIC">"IANA Performance Metric Registry</xref>.</t>

      <t><figure>
          <artwork><![CDATA[
+-----------------------------+-------------------------------------+
|      Performance Metric     |             IPFIX Entity            |
+-----------------------------+-------------------------------------+
|OWDelay_HybridType1_Passive_I|PathDelayMeanDeltaMicroseconds (TBD5)|
|P_RFCTBD_Seconds_Mean (TBD1) |PathDelayMeanDeltaNanoseconds (TBD6) |
+-----------------------------+-------------------------------------+
|OWDelay_HybridType1_Passive_I|PathDelayMinDeltaMicroseconds (TBD7) |
|P_RFCTBD_Seconds_Min (TBD2)  |PathDelayMinDeltaNanoseconds (TBD8)  |
+-----------------------------+-------------------------------------+
|OWDelay_HybridType1_Passive_I|PathDelayMaxDeltaMicroseconds (TBD9) |
|P_RFCTBD_Seconds_Max (TBD3)  |PathDelayMaxDeltaNanoseconds (TBD10) |
+-----------------------------+-------------------------------------+
|OWDelay_HybridType1_Passive_I|PathDelaySumDeltaMicroseconds (TBD11)|
|P_RFCTBD_Seconds_Sum (TBD4)  |PathDelaySumDeltaNanoseconds (TBD12) |
+-----------------------------+-------------------------------------+
          
Table 1: Correspondance between IE and performance metric registry
       ]]></artwork>
        </figure></t>

      <t>The delay is measured by calculating the difference between the
      timestamp imposed with Inband Telemetry in the packet at the IOAM
      encapsulation node and the timestamp exported in the IPFIX flow record
      from the IOAM transit and decapsulation nodes. Depending on the IE, the
      lowest, highest or the sum of measured path delay is being exported.</t>

      <figure anchor="ioam_topology"
              title="IOAM Delay use case. Packets flow from host 1 to host 2.">
        <artwork align="center"><![CDATA[
                                IOAM-Domain
              .........................................
              .                                       .
              .    D1                                 .
              . <------>                              .
              .                                       .
              .          D2                           .
              . <-------------------->                .
              .                                       .
              .                  D3                   .
              . <-----------------------------------> .
              .                                       .
(H1) ------ (R1) ------- (R2) ------- (R3) -------- (R4) ------ (H2)
Host 1  Encapsulation   Transit      Transit   Decapsulation  Host 2
            Node         Node 1       Node 2        Node
              .                                       .
              .                                       .
              .........................................         

]]></artwork>
      </figure>

      <t>On the usecase showed in <xref target="ioam_topology"/> using IOAM to
      export the delay metrics, the node R2 exports the delay D1, the node R3
      exports the delay D2 and the decapsulation node R4 exports the total
      delay D3 using IPFIX.</t>
    </section>

    <section anchor="PM" title="Performance Metrics">
      <t>This section defines and describes the new performance metrics</t>

      <section anchor="ip-ow-delay-hybridtype1-passive-reg-entries"
               title="IP One-Way Delay Hybrid Type I Passive Registry Entries">
        <t>This section specifies four Registry Entries for the Hybrid Type I
        Passive assessment of IP One-Way Delay.</t>

        <t>All column entries besides the ID, Name, Description, and Output
        Reference Method categories are the same; thus, this section defines
        four closely related Registry Entries. As a result, IANA has assigned
        corresponding URLs to each of the four Named Metrics.</t>

        <section numbered="true" title="Summary">
          <t>This category includes multiple indexes to the Registry Entry:
          the element ID and Metric Name.</t>

          <section title="ID (Identifier)">
            <t>&lt;insert a numeric Identifier, an integer, TBD&gt;</t>
          </section>

          <section title="Name">
            <t>IANA has allocated the numeric Identifiers TBD1-4 for the four
            Named Metric Entries in this section</t>
          </section>

          <section title="Name">
            <t>TBD1: OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Mean</t>

            <t>TBD2: OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Min</t>

            <t>TBD3: OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Max</t>

            <t>TBD4: OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Sum</t>
          </section>

          <section title="URI">
            <t>URL: <eref
            target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Mean"/></t>

            <t>URL: <eref
            target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Min"/></t>

            <t>URL: <eref
            target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Max"/></t>

            <t>URL: <eref
            target="https://www.iana.org/assignments/performance-metrics/OWDelay_HybridType1_Passive_IP_RFCTBD_Seconds_Sum"/></t>
          </section>
        </section>

        <section title="Description">
          <t>This metric assesses the one-way delay of IP packets constituting
          a single connection between two hosts. We consider the measurement
          of one-way delay based on a single Observation Point (OP) <xref
          target="RFC7011"/> somewhere in the network. The output is the
          one-way delay for all successfully forwarded packets expressed as
          the &lt;statistic&gt; of their conditional delay distribution, where
          &lt;statistic&gt; is one of:</t>

          <t><list style="symbols">
              <t>Mean</t>

              <t>Min</t>

              <t>Max</t>

              <t>Sum</t>
            </list></t>
        </section>

        <section title="Change Controller">
          <t>IETF</t>
        </section>

        <section title="Version of Registry Format">
          <t>1.0</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the immutable
        document reference and values of input factors, called "Fixed
        Parameters".</t>

        <section title="Reference Definition">
          <t>Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A
          One-Way Delay Metric for IP Performance Metrics (IPPM)", STD 81, RFC
          7679, DOI 10.17487/RFC7679, January 2016,
          &lt;https://www.rfc-editor.org/info/rfc7679&gt;. <xref
          target="RFC7679"/></t>

          <t>Morton, A. and E. Stephan, "Spatial Composition of Metrics", RFC
          6049, DOI 10.17487/RFC6049, January 2011,
          &lt;https://www.rfc-editor.org/info/rfc6049&gt;. <xref
          target="RFC6049"/></t>

          <t>Section 3.4 of <xref target="RFC7679"/> provides the reference
          definition of the singleton (single value) one-way delay metric.
          Section 4.4 of <xref target="RFC7679"/> provides the reference
          definition expanded to cover a multi-value sample. Note that terms
          such as "singleton" and "sample" are defined in section 2 of <xref
          target="RFC2330"/>.</t>

          <t>With the OP <xref target="RFC7011"/> typically located between
          the hosts participating in the IP connection, the one-way delay
          metric requires one individual measurement between the OP and
          sourcing host, such that the Spatial Composition <xref
          target="RFC6049"/> of the measurements yields a one-way delay
          singleton.</t>
        </section>

        <section title="Fixed Parameters">
          <t><figure>
              <preamble>Traffic Filters:</preamble>

              <artwork><![CDATA[
 IPv4 header values:
   DSCP: Set to 0

 IPv6 header values:
   DSCP: Set to 0
   Hop Count: Set to 255
   Flow Label: Set to 0
   Extension Headers: None
          ]]></artwork>
            </figure></t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous method for implementations.</t>

        <section title="Reference Methods">
          <t>The foundational methodology for this metric is defined in
          section 4 of <xref target="RFC7323"/> using the Timestamps option
          with modifications that allow application at a mid-path OP <xref
          target="RFC7011"/>.</t>

          <t>The Traffic Filter at the OP is configured to observe a single IP
          connection.</t>
        </section>

        <section title="Packet Stream Generation">
          <t>N/A</t>
        </section>

        <section title="Traffic Filtering (Observation) Details">
          <t>The Fixed Parameters above give a portion of the Traffic Filter.
          Other aspects will be supplied as Runtime Parameters (below).</t>
        </section>

        <section title="Sampling Distribution">
          <t>This metric requires a partial sample of all packets that qualify
          according to the Traffic Filter criteria.</t>
        </section>

        <section title="Runtime Parameters and Data Format">
          <t>Runtime Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t><list style="hanging">
              <t hangText="Src:">The IP address of the host in the host A Role
              (format ipv4&nbhy;address-no-zone value for IPv4 or
              ipv6-address-no-zone value for IPv6; see section 4 of <xref
              target="RFC6991"/>.</t>

              <t hangText="Dst:">The IP address of the host in the host B Role
              (format ipv4&nbhy;address-no-zone value for IPv4 or
              ipv6-address-no-zone value for IPv6; see section 4 of <xref
              target="RFC6991"/>.</t>

              <t hangText="TTL or Hop Limit:">Set at desired value.</t>

              <t hangText="DSCP:">Set at desired value.</t>

              <t hangText="IPv6 Flow Label:">Set at desired value.</t>

              <t hangText="Timestamp:">The timestamp when the packet is being
              received at IOAM encapsulation node. Format depends on Inband
              Telemetry implementation. For IOAM, Section 4.4.1 of <xref
              target="RFC9197"/> describes what kind of timestamps are
              supported. Section 4.4.2.3 and 4.4.2.4 describe where the
              timestamp is being inserted. For Path Tracing, Section 4.1 of
              <xref target="I-D.filsfils-spring-path-tracing"/> describes what
              kind of timestamps are supported. Section 9.2 describe the SRH
              path tracing TLV where the timestamp is being inserted.</t>
            </list></t>
        </section>

        <section title="Roles">
          <t><list style="hanging">
              <t hangText="host A:">Launches the IP packet to open the
              connection. The Role of "host A" is synonymous with the IP
              address used at host A.</t>

              <t hangText="host B:">Receives the IP packet to open the
              connection. The Role of "host B" is synonymous with the IP
              address used at host B.</t>

              <t hangText="Encapsulation Node:">Receives the IP packet to open
              the connection and encapsulates the timestamp into the packet.
              The Role of "Encapsulation Node" is synonymous with the
              timestamp inserted in the packet.</t>

              <t hangText="Transit Node:">Receives the IP packet to open the
              connection and measures the delay between the timestamp in the
              packet and the timestamp when the packet was received.</t>

              <t hangText="Decapsulation Node:">Receives the IP packet to open
              the connection and measures the delay between the timestamp in
              the packet and the timestamp when the packet was received and
              removes the IOAM header from the packet.</t>
            </list></t>
        </section>
      </section>

      <section title="Output">
        <t>This category specifies all details of the output of measurements
        using the metric.</t>

        <section title="Type">
          <t>OWDelay Types are discussed in the subsections below.</t>
        </section>

        <section title="Reference Definition">
          <t>For all output types:</t>

          <t><list style="hanging">
              <t hangText="OWDelay_HybridType1_Passive_IP:">The one-trip delay
              of one IP packet is a Singleton</t>
            </list></t>

          <t>For each &lt;statistic&gt;, Singleton one of the following
          subsections applies.</t>

          <section title="Mean">
            <t>The mean SHALL be calculated using the conditional distribution
            of all packets with a finite value of one-way delay (undefined
            delays are excluded) -- a single value, as follows:</t>

            <t>See section 4.1 of <xref target="RFC3393"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            see section 5 of <xref target="RFC6703"/> for background on this
            analysis choice.</t>

            <t>See section 4.2.2 of <xref target="RFC6049"/> for details on
            calculating this statistic; see also section 4.2.3 of <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Mean:">The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) with a resolution of
                0.000000001&nbsp;seconds (1.0 ns), and with lossless
                conversion to/from the 64-bit NTP timestamp as per section 6
                of <xref target="RFC5905"/>.</t>
              </list></t>
          </section>

          <section title="Min">
            <t>The minimum SHALL be calculated using the conditional
            distribution of all packets with a finite value of one-way delay
            (undefined delays are excluded) -- a single value, as follows:</t>

            <t>See section 4.1 of <xref target="RFC3393"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            see section 5 of <xref target="RFC6703"/> for background on this
            analysis choice.</t>

            <t>See section 4.3.2 of <xref target="RFC6049"/> for details on
            calculating this statistic; see also section 4.3.3 of <xref
            target="RFC6049"/>.</t>

            <t><list style="hanging">
                <t hangText="Min:">The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) with a resolution of
                0.000000001&nbsp;seconds (1.0 ns), and with lossless
                conversion to/from the 64-bit NTP timestamp as per section 6
                of <xref target="RFC5905"/>.</t>
              </list></t>
          </section>

          <section title="Max">
            <t>The maximum SHALL be calculated using the conditional
            distribution of all packets with a finite value of one-way delay
            (undefined delays are excluded) -- a single value, as follows:</t>

            <t>See section 4.1 of <xref target="RFC3393"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            see section 5 of <xref target="RFC6703"/> for background on this
            analysis choice.</t>

            <t>See section 4.3.2 of <xref target="RFC6049"/> for a closely
            related method for calculating this statistic; see also section
            4.3.3 of <xref target="RFC6049"/>. The formula is as follows:</t>

            <t><figure>
                <artwork><![CDATA[ 
 Max = (FiniteDelay[j])
 such that for some index, j, where 1 <= j <= N
 FiniteDelay[j] >= FiniteDelay[n] for all n
         ]]></artwork>
              </figure></t>

            <t><list style="hanging">
                <t hangText="Max:">The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) with a resolution of
                0.000000001&nbsp;seconds (1.0 ns), and with lossless
                conversion to/from the 64-bit NTP timestamp as per section 6
                of <xref target="RFC5905"/>.</t>
              </list></t>
          </section>

          <section title="Sum">
            <t>The sum SHALL be calculated using the conditional distribution
            of all packets with a finite value of one-way delay (undefined
            delays are excluded) -- a single value, as follows:</t>

            <t>See section 4.1 of <xref target="RFC3393"/> for details on the
            conditional distribution to exclude undefined values of delay, and
            see section 5 of <xref target="RFC6703"/> for background on this
            analysis choice.</t>

            <t>See section 4.3.5 of <xref target="RFC6049"/> for details on
            calculating this statistic. However in this case FiniteDelay or
            MaxDelay MAY be used.</t>

            <t><list style="hanging">
                <t hangText="Sum:">The time value of the result is expressed
                in units of seconds, as a positive value of type decimal64
                with fraction digits = 9 (see section 9.3 of <xref
                target="RFC6020"/>) with a resolution of
                0.000000001&nbsp;seconds (1.0 ns), and with lossless
                conversion to/from the 64-bit NTP timestamp as per section 6
                of <xref target="RFC5905"/>.</t>
              </list></t>
          </section>

          <section title="Metric Units">
            <t>The &lt;statistic&gt; of one-way delay is expressed in seconds,
            where &lt;statistic&gt; is one of:</t>

            <t><list style="symbols">
                <t>Mean</t>

                <t>Min</t>

                <t>Max</t>

                <t>Sum</t>
              </list></t>

            <t>The one-way delay of the IP connection singleton is expressed
            in seconds.</t>
          </section>

          <section title="Calibration">
            <t>Passive Measurements at an OP could be calibrated against an
            Active Measurement at host A where the Active Measurement
            represents the ground truth.</t>
          </section>
        </section>

        <section title="Administrative Items">
          <section title="Status">
            <t>Current</t>
          </section>

          <section title="Requester">
            <t>This RFC</t>
          </section>

          <section title="Revision">
            <t>1.0</t>
          </section>

          <section title="Revision Date">
            <t>RFC Date</t>
          </section>
        </section>

        <section title="Comments and Remarks">
          <t>None</t>
        </section>
      </section>
    </section>

    <section anchor="IE" title="IPFIX Information Elements">
      <t>This section defines and describes the new IPFIX IEs.<list
          style="hanging">
          <t hangText="PathDelayMeanDeltaMicroseconds"><vspace
          blankLines="0"/> 16-bit unsigned integer that identifies the mean
          path delay in microseconds, between the IOAM encapsulation node and
          the local node with the IOAM domain (either an IOAM transit node or
          an IOAM decapsulation node).</t>

          <t hangText="PathDelayMeanDeltaNanoseconds"><vspace blankLines="0"/>
          32-bit unsigned integer that identifies the mean path delay in
          nanoseconds, between the IOAM encapsulation node and the local node
          with the IOAM domain (either an IOAM transit node or an IOAM
          decapsulation node).</t>

          <t hangText="PathDelayMinDeltaMicroseconds"><vspace blankLines="0"/>
          16-bit unsigned integer that identifies the lowest path delay in
          microseconds, between the IOAM encapsulation node and the local node
          with the IOAM domain (either an IOAM transit node or an IOAM
          decapsulation node).</t>

          <t hangText="PathDelayMinDeltaNanoseconds"><vspace blankLines="0"/>
          32-bit unsigned integer that identifies the lowest path delay in
          nanoseconds, between the IOAM encapsulation node and the local node
          with the IOAM domain (either an IOAM transit node or an IOAM
          decapsulation node).</t>

          <t hangText="PathDelayMaxDeltaMicroseconds"><vspace blankLines="0"/>
          16-bit unsigned integer that identifies the highest path delay in
          microseconds, between the IOAM encapsulation node and the local node
          with the IOAM domain (either an IOAM transit node or an IOAM
          decapsulation node).</t>

          <t hangText="PathDelayMaxDeltaNanoseconds"><vspace blankLines="0"/>
          32-bit unsigned integer that identifies the highest path delay in
          nanoseconds, between the IOAM encapsulation node and the local node
          with the IOAM domain (either an IOAM transit node or an IOAM
          decapsulation node).</t>

          <t hangText="PathDelaySumDeltaMicroseconds"><vspace blankLines="0"/>
          32-bit unsigned integer that identifies the sum of the path delay in
          microseconds, between the IOAM encapsulation node and the local node
          with the IOAM domain (either an IOAM transit node or an IOAM
          decapsulation node).</t>

          <t hangText="PathDelaySumDeltaNanoseconds"><vspace blankLines="0"/>
          64-bit unsigned integer that identifies the sum of the path delay in
          nanoseconds, between the IOAM encapsulation node and the local node
          with the IOAM domain (either an IOAM transit node or an IOAM
          decapsulation node).</t>
        </list></t>
    </section>

    <section anchor="Use-Cases" title="Use Cases">
      <t>The measured forwarding path delay can be aggregated with Flow
      Aggregation as defined in <xref target="RFC7015"/> to the following
      device and control-plane dimensions to determine:</t>

      <t><list style="symbols">
          <t>With node id and egressInterface(IE14), on which node which
          logical egress interfaces have been contributing to how much
          delay.</t>

          <t>With node id and egressPhysicalInterface(253), on which node
          which physical egress interfaces have been contributing to how much
          delay.</t>

          <t>With ipNextHopIPv4Address(IE15) or ipNextHopIPv6Address(IE62),
          the forwarding path to which next-hop IP contributed to how much
          delay.</t>

          <t>With mplsTopLabelIPv4Address(IE47) or srhActiveSegmentIPv6 from
          <xref target="I-D.tgraf-opsawg-ipfix-srv6-srh"/>, the forwarding
          path to which MPLS top label IPv4 address or SRv6 active segment
          contributed to how much delay.</t>

          <t>BGP communities are often used for setting a path priority or
          service selection. With bgpDestinationExtendedCommunityList(488) or
          bgpDestinationCommunityList(485) or
          bgpDestinationLargeCommunityList(491) which group of prefixes
          accumulated at which node how much delay.</t>

          <t>With destinationIPv4Address(13), destinationTransportPort(11),
          protocolIdentifier (4) and sourceIPv4Address(IE8), the forwarding
          path delay on each node from each IPv4 source address to a specific
          application in the network.</t>
        </list></t>

      <t>Taking figure 1 from section 1 as topology example. Below example
      table shows the aggregated delay per each node, egressInterface and
      srhActiveSegmentIPv6.</t>

      <t><figure>
          <artwork><![CDATA[
     +------------+------+-----------------+----------------------+
     | Path Delay | Node | egressInterface | srhActiveSegmentIPv6 |
     +------------+------+-----------------+----------------------+
     |     0 ns   |  R1  |      276        |      2001:db8::4     |
     +------------+------+-----------------+----------------------+
     |  3122 ns   |  R2  |      312        |      2001:db8::4     |
     +------------+------+-----------------+----------------------+
     |  4432 ns   |  R3  |       27        |      2001:db8::4     |
     +------------+------+-----------------+----------------------+
     |  7237 ns   |  R4  |      854        |      2001:db8::4     |
     +------------+------+-----------------+----------------------+

  Table 2: Example table of measured delay. Ascending by delay.
       ]]></artwork>
        </figure></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <section anchor="PM-IANA" title="Performance Metrics">
        <t>This document requests IANA to create new performance metrics under
        the "Performance Metrics" registry <xref target="RFC8911"/> with the
        values defined in section 2.</t>
      </section>

      <section anchor="IE-IANA" title="IPFIX Entities">
        <t>This document requests IANA to create new IEs (see table 3) under
        the "IPFIX Information Elements" registry <xref target="RFC7012"/>
        available at <xref target="IANA-PERF-METRIC">"IANA Performance Metric
        Registry</xref> and assign the following initial code points.</t>

        <t><figure>
            <artwork><![CDATA[
     +-------+--------------------------------+
     |Element|              Name              |
     |   ID  |                                |
     +-------+--------------------------------+
     | TBD5  | PathDelayMeanDeltaMicroseconds |
     |       |                                |
     +-------+--------------------------------+
     | TBD6  | PathDelayMeanDeltaNanoseconds  |
     |       |                                |
     +-------+--------------------------------+
     | TBD7  | PathDelayMinDeltaMicroseconds  |
     |       |                                |
     +-------+--------------------------------+
     | TBD8  | PathDelayMinDeltaNanoseconds   |
     |       |                                |
     +-------+--------------------------------+
     | TBD9  | PathDelayMaxDeltaMicroseconds  |
     |       |                                |
     +-------+--------------------------------+
     | TBD10 | PathDelayMaxDeltaNanoseconds   |
     |       |                                |
     +-------+--------------------------------+
     | TBD11 | PathDelaySumDeltaMicroseconds  |
     |       |                                |
     +-------+--------------------------------+
     | TBD12 | PathDelaySumDeltaNanoseconds   |
     |       |                                |
     +-------+--------------------------------+
  Table 3: Creates IEs in the "IPFIX Information Elements" registry
       ]]></artwork>
          </figure></t>

        <t>Note to the RFC-Editor:</t>

        <t><list style="symbols">
            <t>Please replace TBD5 - TBD12 with the values allocated by
            IANA</t>

            <t>Please replace the [RFC-to-be] with the RFC number assigned to
            this document</t>
          </list></t>

        <section anchor="IANAPathDelayMeanDeltaMicroseconds"
                 title="PathDelayMeanDeltaMicroseconds">
          <t>Name: PathDelayMeanDeltaMicroseconds <vspace blankLines="0"/>
          ElementID: TBD5 <vspace blankLines="0"/> Description: This
          Information Element identifies the mean path delay between the IOAM
          encapsulation node and the local node with the IOAM domain (either
          an IOAM transit node or an IOAM decapsulation node) in microseconds.
          <vspace blankLines="0"/> Abstract Data Type: unsigned16 <vspace
          blankLines="0"/> Data Type Semantics: OctedDelta <vspace
          blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>

        <section anchor="IANAPathDelayMeanDeltaNanoseconds"
                 title="PathDelayMeanDeltaNanoseconds">
          <t>Name: PathDelayMeanDeltaNanoseconds <vspace blankLines="0"/>
          ElementID: TBD6 <vspace blankLines="0"/> Description: This
          Information Element identifies the mean path delaybetween the IOAM
          encapsulation node and the local node with the IOAM domain (either
          an IOAM transit node or an IOAM decapsulation node) in nanoseconds.
          <vspace blankLines="0"/> Abstract Data Type: unsigned32 <vspace
          blankLines="0"/> Data Type Semantics: OctedDelta <vspace
          blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>

        <section anchor="IANAPathDelayMinDeltaMicroseconds"
                 title="PathDelayMinDeltaMicroseconds">
          <t>Name: PathDelayMinDeltaMicroseconds <vspace blankLines="0"/>
          ElementID: TBD7 <vspace blankLines="0"/> Description: This
          Information Element identifies the lowest path delay between the
          IOAM encapsulation node and the local node with the IOAM domain
          (either an IOAM transit node or an IOAM decapsulation node) in
          microseconds. <vspace blankLines="0"/> Abstract Data Type:
          unsigned16 <vspace blankLines="0"/> Data Type Semantics: OctedDelta
          <vspace blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>

        <section anchor="IANAPathDelayMinDeltaNanoseconds"
                 title="PathDelayMinDeltaNanoseconds">
          <t>Name: PathDelayMinDeltaNanoseconds <vspace blankLines="0"/>
          ElementID: TBD8 <vspace blankLines="0"/> Description: This
          Information Element identifies the lowest path delay between the
          IOAM encapsulation node and the local node with the IOAM domain
          (either an IOAM transit node or an IOAM decapsulation node) in
          nanoseconds. <vspace blankLines="0"/> Abstract Data Type: unsigned32
          <vspace blankLines="0"/> Data Type Semantics: OctedDelta <vspace
          blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>

        <section anchor="IANAPathDelayMaxDeltaMicroseconds"
                 title="PathDelayMaxDeltaMicroseconds">
          <t>Name: PathDelayMaxDeltaMicroseconds <vspace blankLines="0"/>
          ElementID: TBD9 <vspace blankLines="0"/> Description: This
          Information Element identifies the highest path delay between the
          IOAM encapsulation node and the local node with the IOAM domain
          (either an IOAM transit node or an IOAM decapsulation node) in
          microseconds. <vspace blankLines="0"/> Abstract Data Type:
          unsigned16 <vspace blankLines="0"/> Data Type Semantics: OctedDelta
          <vspace blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>

        <section anchor="IANAPathDelayMaxDeltaNanoseconds"
                 title="PathDelayMaxDeltaNanoseconds">
          <t>Name: PathDelayMaxDeltaNanoseconds <vspace blankLines="0"/>
          ElementID: TBD10 <vspace blankLines="0"/> Description: This
          Information Element identifies the highest path delay between the
          IOAM encapsulation node and the local node with the IOAM domain
          (either an IOAM transit node or an IOAM decapsulation node) in
          nanoseconds. <vspace blankLines="0"/> Abstract Data Type: unsigned32
          <vspace blankLines="0"/> Data Type Semantics: OctedDelta <vspace
          blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>

        <section anchor="IANAPathDelaySumDeltaMicroseconds"
                 title="PathDelaySumDeltaMicroseconds">
          <t>Name: PathDelaySumDeltaMicroseconds <vspace blankLines="0"/>
          ElementID: TBD11 <vspace blankLines="0"/> Description: This
          Information Element identifies the sum of the path delay between the
          IOAM encapsulation node and the local node with the IOAM domain
          (either an IOAM transit node or an IOAM decapsulation node) in
          microseconds. <vspace blankLines="0"/> Abstract Data Type:
          unsigned32 <vspace blankLines="0"/> Data Type Semantics: OctedDelta
          <vspace blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>

        <section anchor="IANAPathDelaySumDeltaNanoseconds"
                 title="PathDelaySumDeltaNanoseconds">
          <t>Name: PathDelaySumDeltaNanoseconds <vspace blankLines="0"/>
          ElementID: TBD12 <vspace blankLines="0"/> Description: This
          Information Element identifies the sum of the path delay between the
          IOAM encapsulation node and the local node with the IOAM domain
          (either an IOAM transit node or an IOAM decapsulation node) in
          nanoseconds. <vspace blankLines="0"/> Abstract Data Type: unsigned64
          <vspace blankLines="0"/> Data Type Semantics: OctedDelta <vspace
          blankLines="0"/> Reference: [RFC-to-be], xxx</t>
        </section>
      </section>
    </section>

    <section anchor="Operational" title="Operational Considerations">
      <section anchor="OpsTimeAccuracy" title="Time Accuracy">
        <t>The same recommendation as defined in section 4.5 of <xref
        target="RFC5153"/> for IPFIX applies in terms of clock precision to
        this document as well.</t>
      </section>

      <section anchor="OpsMeanDelay" title="Mean Delay">
        <t>The mean (average) path delay can be calculated by dividing the
        PathDelaySumDeltaMicroseconds(TBD5) or
        PathDelaySumDeltaNanoseconds(TBD6) by the packetDeltaCount(2) at the
        IPFIX data collection.</t>
      </section>

      <section anchor="OpsIoamPackTimestamps" title="IOAM Packet Time Stamps">
        <t>For IOAM, Section 4.4.1 of <xref target="RFC9197"/> describes what
        kind of timestamps are supported. Section 4.4.2.3 and 4.4.2.4 describe
        where the timestamp is being inserted.</t>

        <t>For Path Tracing, Section 4.1 of <xref
        target="I-D.filsfils-spring-path-tracing"/> describes what kind of
        timestamps are supported. Section 9.2 describe the SRH path tracing
        TLV where the timestamp is being inserted.</t>
      </section>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>There are no significant extra security considerations regarding the
      allocation of these new IPFIX IEs compared to <xref
      target="RFC7012"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank xxx for their review and valuable
      comments.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.7012'?>

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

      <reference anchor="IANA-PERF-METRIC"
                 target="https://www.iana.org/assignments/performance-metrics/performance-metrics.xhtml">
        <front>
          <title>IANA Performance Metric Registry</title>

          <author/>

          <date/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.I-D.ietf-ippm-ioam-deployment'?>

      <?rfc include='reference.I-D.filsfils-spring-path-tracing'?>

      <?rfc include='reference.I-D.song-opsawg-ifit-framework'?>

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

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

      <?rfc include='reference.I-D.song-ippm-postcard-based-telemetry'?>

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

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

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

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

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

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

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

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

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

      <?rfc include='reference.I-D.tgraf-opsawg-ipfix-srv6-srh'?>

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

      <?rfc include='reference.RFC.7015'?>
    </references>
  </back>
</rfc>