[ippm] IOAM Direct Exporting Open Issue

[Tal Mizrahi <[e-mail]>]

Hi,

There is an open issue in the DEX draft about whether to include an
explicit Hop Count field in the DEX header, or to rely on the existing
Hop_Lim/Node_ID data field.

Section 7 of the draft presents the pros and cons of each of these
alternatives. This issue has also been discussed on the mailing list a
couple of times, and on the last few IPPM meetings.

We would like to encourage non-authors to express their opinion about
which approach should be taken: (1) use an explicit Hop Count field,
or (2) rely on the existing Hop_Lim/Node_ID data field.

Cheers,
Tal.


Here is a link to the draft:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-direct-export/

Section 7 of the draft, which presents the two alternatives is quoted
here for convenience.

      Hop Limit / Hop Count: in order to help correlate and order the
      exported packets, it is possible to include a 1-octet Hop Count
      field in the DEX header (presumably by claiming some space from
      the Flags field).  Its value starts from 0 at the encapsulating
      node and is incremented by each IOAM transit node that supports
      the DEX option.  The Hop Count field value is also included in the
      exported packet.  An alternative approach is to use the Hop_Lim/
      Node_ID data field; if the IOAM-Trace-Type
      [I-D.ietf-ippm-ioam-data] has the Hop_Lim/Node_ID bit set, then
      exported packets include the Hop_Lim/Node_ID data field, which
      contains the TTL/Hop Limit value from a lower layer protocol.  The
      main advantage of the Hop_Lim/Node_ID approach is that it provides
      information about the current hop count without requiring each
      transit node to modify the DEX option, thus simplifying the data
      plane functionality of Direct Exporting.  The main advantage of
      the Hop Count approach is that it counts the number of IOAM-
      capable nodes without relying on the lower layer TTL, especially
      when the lower layer cannot prvide the accurate TTL information,
      e.g., Layer 2 Ethernet or hierarchical VPN.  It also explicitly
      allows to detect a case where an IOAM-capable node fails to export
      packets.  In order to facilitate the Hop Count approach it is
      possible to use a flag to indicate an optional Hop Count field,
      which enables to control the tradeoff.  On one hand it addresses
      the use cases that the Hop_Lim/Node_ID cannot cover, and on the
      other hand it does not require transit switches to update the
      option if it is not supported or disabled.  Further discussion is
      required about the tradeoff between the two alternatives.