7. Operational Considerations

Cette section conserve le texte RFC relatif à l'IPFIX delay performance metric export, y compris On-Path Telemetry, OAM nodes, Flow Records, performance metric IDs 27-30, IPFIX Information Elements 530-533, IANA registrations, operational guidance et encoding examples.

Texte RFC original

7.  Operational Considerations

7.1.  Time Accuracy

   In terms of clock precision, the same recommendation as defined in
   Section 4.5 of [RFC5153] for IPFIX applies to this document as well.

7.2.  Mean Delay

   The mean (average) path delay can be calculated by dividing the
   pathDelaySumDeltaMicroseconds(533) by the packetDeltaCount(2) at the
   IPFIX data collection at the collection time instead of the IPFIX
   Exporter at the export time.

7.3.  Reduced-Size Encoding

   Unsigned64 has been chosen as the type for
   pathDelaySumDeltaMicroseconds to support cases with large delay
   numbers and where many packets are being counted.  As an example, a
   specific Flow Record with path delay of 100 milliseconds cannot
   observe more than 42949 packets without overflowing the unsigned32
   counter.  The procedure described in Section 6.2 of [RFC7011] may be
   applied to reduce network bandwidth between the IPFIX Exporter and
   Collector if unsigned32 would be large enough without wrapping
   around.

7.4.  Measurement Interval

   The delay metrics are computed for the Flow Record lifetime by
   comparing the OAM timestamps in each received packet with the
   timestamp when they were received.  For a long-running Flow, the
   IPFIX Metering Process might miss the temporal distribution of the
   delay (for example, a longer delay only at the beginning of the
   Flow).  If this is an operational problem, the IPFIX Metering Process
   might be configured with a smaller expiration timeout (see "Flow
   Expiration", Section 5.1.1 of [RFC5470]).

7.5.  In-Packet OAM Application

   Multiple methods can be used to compute the delay performance metrics
   defined in this document.  Some examples of such methods are IOAM
   [RFC9197] and Enhanced Alternate Marking [ENH-ALT-MARKING].

   For IOAM, these performance metrics can be computed using the Edge-
   to-Edge and the Direct Exporting Option-Type.

   IOAM Edge-to-Edge Option-Type, as described in Section 4.6 of
   [RFC9197], can use bits 2 and 3.  In this case, timestamps are
   encoded as defined in Sections 4.4.2.3 and 4.4.2.4 of [RFC9197].
   This timestamp can be used to compute the delay between an OAM header
   encapsulating node and the decapsulating node.

   The IOAM Direct Exporting Option-Type, as described in [RFC9326], can
   use the Extension-Flag defined in [IOAM-DEX] to insert a timestamp in
   the OAM header encapsulating node.  The timestamp is encoded as
   defined in Sections 4.4.2.3 and 4.4.2.4 of [RFC9197].  This timestamp
   can be used to compute the delay between the inserted timestamp and
   the OAM header transit and decapsulating node.

   For the Enhanced Alternate Marking Method, Section 2 of
   [ENH-ALT-MARKING] and Section 3.2 of [RFC9947] define that, within
   the metaInfo, a nanosecond timestamp can be encoded in an OAM header
   encapsulating node and be read at the OAM header intermediate and
   decapsulating nodes to calculate the On-path delay.  [RFC9343]
   defines how this can be applied to the IPv6 extensions header, and
   [RFC9947] defines how this can be applied to the SRv6 Segment Routing
   Header [RFC8754].

   Given that the delay measurements are computed with the timestamp
   introduced on the OAM header encapsulating node, regardless of the
   approach, implementations should document at which point of the
   forwarding plane this timestamp is introduced (e.g., the time at
   which the packet was received by the node, the time at which the
   packet was transmitted by the node, etc.).  Based on this
   information, different actions can be taken.