Export of Delay Performance Metrics in IP Flow Information eXport (IPFIX)
draft-ietf-opsawg-ipfix-on-path-telemetry-23

Hi Thomas, Benoît, and Alex, 

Thank your for the effort put into this specification. Interesting to see the approach defined in RFC 8911 exercised here.

Also, thanks to Menachem Dodge for the OPSDIR review and Qin Wu for the PERFMETRDIR review. Appreciate that Menachem, Qin, and authors converged for both reviews. 

As I reviewed a previous version of the spec [1], I only focused the current review on the diff since then [2]. I specifically appreciated the new text added to explain the need for the IEs compared to an approach where intermediate nodes export the timestamps observed in packets and local receiving timestamps and let the collector to do the various math operations. Likewise, I appreciate that the IEs were generalized to be independent of IOAM.

I only have very minor comments:

# Use the exact registry name

## Section 1

OLD:
   In order to export the delay-related metrics via IPFIX [RFC7011],
   this document defines four new IPFIX Information Elements (IEs),
   exposing the On-Path delay on OAM transit and decapsulating nodes,
   following the postcard mode principles.  Since these IPFIX IEs are
   performance metrics [RFC8911], they are also registered in the "IANA
   Performance Metric Registry [IANA-PERF-METRIC].

NEW:
   In order to export the delay-related metrics via IPFIX [RFC7011],
   this document defines four new IPFIX Information Elements (IEs),
   exposing the On-Path delay on OAM transit and decapsulating nodes,
   following the postcard mode principles.  Since these IPFIX IEs are
   performance metrics [RFC8911], they are also registered in the IANA
   “Performance Metric” Registry [IANA-PERF-METRIC].

## Section 1

OLD:
   Following the guidelines for Registered Performance Metric Requesters
   and Reviewers [RFC8911], the different characteristics of the
   performance metrics (Identifier, Name, URI, Status, Requester,
   Revision, Revision Date, Description, etc.) must be clearly specified
   in the "IANA Performance Metric Registry [IANA-PERF-METRIC] in order

NEW:
   Following the guidelines for Registered Performance Metric Requesters
   and Reviewers [RFC8911], the different characteristics of the
   performance metrics (Identifier, Name, URI, Status, Requester,
   Revision, Revision Date, Description, etc.) must be clearly specified
   in the IANA "Performance Metric” Registry [IANA-PERF-METRIC] in order

## Section 3.1

OLD:
   This section specifies four performance metrics for the Hybrid Type I
   Passive assessment of IP One-Way Delay, to be registered in the "IANA
   Performance Metric Registry [IANA-PERF-METRIC].

NEW:
   This section specifies four performance metrics for the Hybrid Type I
   Passive assessment of IP One-Way Delay, to be registered in the IANA
   “Performance Metric” Registry [IANA-PERF-METRIC].

# There might be multiple OAM encapsulating nodes

OLD:
   Assuming time synchronization on devices, the delay is measured by
   calculating the difference between the timestamp imposed with On-Path
   Telemetry in the packet at the OAM encapsulating node and the
                              ^^^^  

NEW:
   Assuming time synchronization on devices, the delay is measured by
   calculating the difference between the timestamp imposed with On-Path
   Telemetry in the packet at an OAM encapsulating node and the

Please check other similar constructs.

# I don’t remember I have seen “flow packet” used in other IPFIX specs + there might be many OAM headers

RFC7011 defines flow as follows: 

      A Flow is defined as a set of packets or frames passing an
      Observation Point in the network during a certain time interval.
      All packets belonging to a particular Flow have a set of common
      properties.

I suggest we make this change:

OLD:
   *  Encapsulating Node: Receives the IP Flow packets, encapsulates the
                                          ^^^^^^^^^^^^
      packets with the OAM header and adds the timestamp into the OAM
      header.

   *  Transit Node: Receives the IP Flow packets, measures the delay^
                                    ^^^^^^^^^^^^
      between the timestamp in the packet and the timestamp when the
      packet was received.

   *  Decapsulating Node: Receives the IP Flow packets, computes the
                                          ^^^^^^^^^^^^
      delay between the timestamp in the packet and the timestamp when
      the packet was received and removes the OAM header from the
      packet.

NEW:
   *  Encapsulating Node: Receives the IP packets, encapsulates the
      packets with an OAM header and adds the timestamp into the OAM
                   ^^
      header.

   *  Transit Node: Receives the IP packets, measures the delay
      between the timestamp in the packet and the timestamp when the
      packet was received.

   *  Decapsulating Node: Receives the IP Flow packets, computes the
      delay between the timestamp in the packet and the timestamp when
      the packet was received and removes the OAM header from the
      packet.

# Please add “Collector” and “Observation Point” to the list of terms under 7011

CURRENT:
  The following terms are used as defined in [RFC7011]:
   …

# (Nit) Only one term is imported from 7799

OLD:
   The following terms are used as defined in Section 3.8 of [RFC7799]:

   *  Hybrid Type I Passive

NEW:
   The following term is used as defined in Section 3.8 of [RFC7799]:

   *  Hybrid Type I Passive

# (nit) Section 3.1.2

OLD:
     We consider the
     measurement of one-way delay based on a single Observation Point
     [RFC7011] somewhere in the network.

NEW:
     The
     measurement of one-way delay is based on a single Observation Point
     [RFC7011] somewhere in the network.

Please make the same change for other similar constructs in the document.

# IANA is the authoritative reference for IEs, not RFC7012 & Use the exact registry names 

OLD:
 5.2.  IPFIX Entities

   This document requests IANA to register new IPFIX IEs (see table 3)
   under the "IPFIX Information Elements" registry [RFC7012] available
   at "IANA IP Flow Information Export (IPFIX) Entities Registry
   [IANA-IPFIX] and assign the following initial code points.

NEW:
 5.2.  IPFIX Entities

   This document requests IANA to register new IPFIX IEs (see table 3)
   under the "IPFIX Information Elements" registry  under
   the " IP Flow Information Export (IPFIX) Entities” registry group
   [IANA-IPFIX] and assign the following initial code points.

# RFC-to-be

There are several notes to the RFC editor with distinct patterns [RCC-to-be] vs. _RFC[RFC-to-be] 

(1) with RFC label

778	   Reference:  [RFC-to-be]

(2) without RFC label

…
781	      OWDelay_HybridType1_Passive_IP_RFC[RFC-to-be]_Seconds_Mean in the
782	      IANA Performance Metric Registry.

Hope this won't be confusing for the RFC editor.

#  Section 6.5

## nit

s/Section 4.4.2.3 and 4.4.2.4 of [RFC9197]/ Sections 4.4.2.3 and 4.4.2.4 of [RFC9197]

There are many such occurrences in the doc.

## Cite  RFC8754

CURRENT:
919	   be applied to the SRv6 Segment Routing Header.

Hope this helps.

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/opsawg/qRNGYGSasUsON8PUvpqrP86ojyo/ 

[2] https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-ipfix-on-path-telemetry-08&url2=draft-ietf-opsawg-ipfix-on-path-telemetry-20&difftype=--html