doc: Add RFC documents

1 files changed, 687 insertions, 0 deletions

diff --git a/doc/rfc/rfc9326.txt b/doc/rfc/rfc9326.txt
new file mode 100644
index 0000000..8713bf8
--- /dev/null
+++ b/doc/rfc/rfc9326.txt
@@ -0,0 +1,687 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           H. Song
+Request for Comments: 9326                                     Futurewei
+Category: Standards Track                                       B. Gafni
+ISSN: 2070-1721                                                   Nvidia
+                                                            F. Brockners
+                                                                   Cisco
+                                                             S. Bhandari
+                                                             Thoughtspot
+                                                              T. Mizrahi
+                                                                  Huawei
+                                                           November 2022
+
+
+   In Situ Operations, Administration, and Maintenance (IOAM) Direct
+                               Exporting
+
+Abstract
+
+   In situ Operations, Administration, and Maintenance (IOAM) is used
+   for recording and collecting operational and telemetry information.
+   Specifically, IOAM allows telemetry data to be pushed into data
+   packets while they traverse the network.  This document introduces a
+   new IOAM option type (denoted IOAM-Option-Type) called the "IOAM
+   Direct Export (DEX) Option-Type".  This Option-Type is used as a
+   trigger for IOAM data to be directly exported or locally aggregated
+   without being pushed into in-flight data packets.  The exporting
+   method and format are outside the scope of this document.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9326.
+
+Copyright Notice
+
+   Copyright (c) 2022 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions
+     2.1.  Requirements Language
+     2.2.  Terminology
+   3.  The Direct Exporting (DEX) IOAM-Option-Type
+     3.1.  Overview
+       3.1.1.  DEX Packet Selection
+       3.1.2.  Responding to the DEX Trigger
+     3.2.  The DEX Option-Type Format
+   4.  IANA Considerations
+     4.1.  IOAM Type
+     4.2.  IOAM DEX Flags
+     4.3.  IOAM DEX Extension-Flags
+   5.  Performance Considerations
+   6.  Security Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Appendix A.  Notes about the History of This Document
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   IOAM [RFC9197] is used for monitoring traffic in the network and for
+   incorporating IOAM data fields (denoted IOAM-Data-Fields) into in-
+   flight data packets.
+
+   IOAM makes use of four possible IOAM-Option-Types, defined in
+   [RFC9197]: Pre-allocated Trace, Incremental Trace, Proof of Transit
+   (POT), and Edge-to-Edge.
+
+   This document defines a new IOAM-Option-Type called the "IOAM Direct
+   Export (DEX) Option-Type".  This Option-Type is used as a trigger for
+   IOAM nodes to locally aggregate and process IOAM data and/or to
+   export it to a receiving entity (or entities).  Throughout the
+   document, this functionality is referred to as "collection" and/or
+   "exporting".  In this context, a "receiving entity" is an entity that
+   resides within the IOAM domain such as a collector, analyzer,
+   controller, decapsulating node, or software module in one of the IOAM
+   nodes.
+
+   Note that even though the IOAM-Option-Type is called "Direct Export",
+   it depends on the deployment whether the receipt of a packet with a
+   DEX Option-Type leads to the creation of another packet.  Some
+   deployments might simply use the packet with the DEX Option-Type to
+   trigger local processing of Operations, Administration, and
+   Maintenance (OAM) data.  The functionality of this local processing
+   is not within the scope of this document.
+
+2.  Conventions
+
+2.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.2.  Terminology
+
+   Abbreviations used in this document:
+
+   IOAM:   In situ Operations, Administration, and Maintenance
+
+   OAM:    Operations, Administration, and Maintenance [RFC6291]
+
+   DEX:    Direct Exporting
+
+3.  The Direct Exporting (DEX) IOAM-Option-Type
+
+3.1.  Overview
+
+   The DEX Option-Type is used as a trigger for collecting IOAM data
+   locally or exporting it to a receiving entity (or entities).
+   Specifically, the DEX Option-Type can be used as a trigger for
+   collecting IOAM data by an IOAM node and locally aggregating it;
+   thus, this aggregated data can be periodically pushed to a receiving
+   entity or pulled by a receiving entity on-demand.
+
+   This Option-Type is incorporated into data packets by an IOAM
+   encapsulating node and removed by an IOAM decapsulating node, as
+   illustrated in Figure 1.  The Option-Type can be read, but not
+   modified, by transit nodes.  Note that the terms "IOAM encapsulating
+   node", "IOAM decapsulating node", and "IOAM transit node" are as
+   defined in [RFC9197].
+
+                                      ^
+                                      |Exported IOAM data
+                                      |
+                                      |
+                                      |
+                +--------------+------+-------+--------------+
+                |              |              |              |
+                |              |              |              |
+  User      +---+----+     +---+----+     +---+----+     +---+----+
+  packets   |Encapsu-|     | Transit|     | Transit|     |Decapsu-|
+  --------->|lating  |====>| Node   |====>| Node   |====>|lating  |---->
+            |Node    |     | A      |     | B      |     |Node    |
+            +--------+     +--------+     +--------+     +--------+
+            Insert DEX       Export         Export       Remove DEX
+            option and      IOAM data      IOAM data     option and
+            export data                                  export data
+
+                        Figure 1: DEX Architecture
+
+   The DEX Option-Type is used as a trigger to collect and/or export
+   IOAM data.  The trigger applies to transit nodes, the decapsulating
+   node, and the encapsulating node:
+
+   *  An IOAM encapsulating node configured to incorporate the DEX
+      Option-Type encapsulates the packets (or possibly a subset of the
+      packets) it forwards with the DEX Option-Type and MAY export and/
+      or collect the requested IOAM data immediately.  Only IOAM
+      encapsulating nodes are allowed to add the DEX Option-Type to a
+      packet.  An IOAM encapsulating node can generate probe packets
+      that incorporate the DEX Option-Type.  These probe packets can be
+      generated periodically or on-demand (for example, triggered by the
+      management plane).  The specification of such probe packets is
+      outside the scope of this document.
+
+   *  A transit node that processes a packet with the DEX Option-Type
+      MAY export and/or collect the requested IOAM data.
+
+   *  An IOAM decapsulating node that processes a packet with the DEX
+      Option-Type MAY export and/or collect the requested IOAM data and
+      MUST decapsulate the IOAM header.
+
+   As in [RFC9197], the DEX Option-Type can be incorporated into all or
+   a subset of the traffic that is forwarded by the encapsulating node,
+   as further discussed in Section 3.1.1.  Moreover, IOAM nodes respond
+   to the DEX trigger by exporting and/or collecting IOAM data either
+   for all traversing packets that carry the DEX Option-Type or
+   selectively only for a subset of these packets, as further discussed
+   in Section 3.1.2.
+
+3.1.1.  DEX Packet Selection
+
+   If an IOAM encapsulating node incorporates the DEX Option-Type into
+   all the traffic it forwards, it may lead to an excessive amount of
+   exported data, which may overload the network and the receiving
+   entity.  Therefore, an IOAM encapsulating node that supports the DEX
+   Option-Type MUST support the ability to incorporate the DEX Option-
+   Type selectively into a subset of the packets that are forwarded by
+   the IOAM encapsulating node.
+
+   Various methods of packet selection and sampling have been previously
+   defined, such as [RFC7014] and [RFC5475].  Similar techniques can be
+   applied by an IOAM encapsulating node to apply DEX to a subset of the
+   forwarded traffic.
+
+   The subset of traffic that is forwarded or transmitted with a DEX
+   Option-Type SHOULD NOT exceed 1/N of the interface capacity on any of
+   the IOAM encapsulating node's interfaces.  It is noted that this
+   requirement applies to the total traffic that incorporates a DEX
+   Option-Type, including traffic that is forwarded by the IOAM
+   encapsulating node and probe packets that are generated by the IOAM
+   encapsulating node.  In this context, N is a parameter that can be
+   configurable by network operators.  If there is an upper bound, M, on
+   the number of IOAM transit nodes in any path in the network, then it
+   is RECOMMENDED to use an N such that N >> M (i.e., N is much greater
+   than M).  The rationale is that a packet that includes a DEX Option-
+   Type may trigger an exported packet from each IOAM transit node along
+   the path for a total of M exported packets.  Thus, if N >> M, then
+   the number of exported packets is significantly lower than the number
+   of data packets forwarded by the IOAM encapsulating node.  If there
+   is no prior knowledge about the network topology or size, it is
+   RECOMMENDED to use N>100.
+
+3.1.2.  Responding to the DEX Trigger
+
+   The DEX Option-Type specifies which IOAM-Data-Fields should be
+   exported and/or collected, as specified in Section 3.2.  As mentioned
+   above, the data can be locally collected, aggregated, and/or exported
+   to a receiving entity proactively or on-demand.  If IOAM data is
+   exported, the format and encapsulation of the packet that contains
+   the exported data is not within the scope of the current document.
+   For example, the export format can be based on [IOAM-RAWEXPORT].
+
+   An IOAM node that performs DEX-triggered exporting MUST support the
+   ability to limit the rate of the exported packets.  The rate of
+   exported packets SHOULD be limited so that the number of exported
+   packets is significantly lower than the number of packets that are
+   forwarded by the device.  The exported data rate SHOULD NOT exceed 1/
+   N of the interface capacity on any of the IOAM node's interfaces.  It
+   is RECOMMENDED to use N>100.  Depending on the IOAM node's
+   architecture considerations, the export rate may be limited to a
+   lower number in order to avoid loading the IOAM node.  An IOAM node
+   MAY maintain a counter or a set of counters that count the events in
+   which the IOAM node receives a packet with the DEX Option-Type and
+   does not collect and/or export data due to the rate limits.
+
+   IOAM nodes SHOULD NOT be configured to export packets over a path or
+   a tunnel that is subject to IOAM direct exporting.  Furthermore, IOAM
+   encapsulating nodes that can identify a packet as an IOAM exported
+   packet MUST NOT push a DEX Option-Type into such a packet.  This
+   requirement is intended to prevent nested exporting and/or exporting
+   loops.
+
+   A transit or decapsulating IOAM node that receives an unknown IOAM-
+   Option-Type ignores it (as defined in [RFC9197]); specifically, nodes
+   that do not support the DEX Option-Type ignore it.  As per [RFC9197],
+   note that a decapsulating node removes the IOAM encapsulation and all
+   its IOAM-Option-Types.  Specifically, this applies to the case where
+   one of these options is a (possibly unknown) DEX Option-Type.  The
+   ability to skip over a (possibly unknown) DEX Option-Type in the
+   parsing or in the decapsulation procedure is dependent on the
+   specific encapsulation, which is outside the scope of this document.
+   For example, when IOAM is encapsulated in IPv6 [IOAM-IPV6-OPTIONS],
+   the DEX Option-Type is incorporated either in a Hop-by-Hop options
+   header or in a Destination options header; thus, it can be skipped
+   using the length field in the options header.
+
+3.2.  The DEX Option-Type Format
+
+   The format of the DEX Option-Type is depicted in Figure 2.  The
+   length of the DEX Option-Type is at least 8 octets.  The DEX Option-
+   Type MAY include one or more optional fields.  The existence of the
+   optional fields is indicated by the corresponding flags in the
+   Extension-Flags field.  Two optional fields are defined in this
+   document: the Flow ID and Sequence Number fields.  Every optional
+   field MUST be exactly 4 octets long.  Thus, the Extension-Flags field
+   explicitly indicates the length of the DEX Option-Type.  Defining a
+   new optional field requires an allocation of a corresponding flag in
+   the Extension-Flags field, as specified in Section 4.2.
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        Namespace-ID           |     Flags     |Extension-Flags|
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               IOAM-Trace-Type                 |   Reserved    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Flow ID (Optional)                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                     Sequence Number  (Optional)               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 2: DEX Option-Type Format
+
+   Namespace-ID:
+      A 16-bit identifier of the IOAM namespace, as defined in
+      [RFC9197].
+
+   Flags:
+      An 8-bit field, comprised of 8 1-bit subfields.  Flags are
+      allocated by IANA, as defined in Section 4.2.
+
+   Extension-Flags:
+      An 8-bit field, comprised of 8 1-bit subfields.  Extension-Flags
+      are allocated by IANA, as defined in Section 4.3.  Every bit in
+      the Extension-Flag field that is set to 1 indicates the existence
+      of a corresponding optional 4-octet field.  An IOAM node that
+      receives a DEX Option-Type with an unknown flag set to 1 MUST
+      ignore the corresponding optional field.
+
+   IOAM-Trace-Type:
+      A 24-bit identifier that specifies which IOAM-Data-Fields should
+      be exported.  The format of this field is as defined in [RFC9197].
+      Specifically, the bit that corresponds to the Checksum Complement
+      IOAM-Data-Field SHOULD be assigned to be zero by the IOAM
+      encapsulating node and ignored by transit and decapsulating nodes.
+      The reason for this is that the Checksum Complement is intended
+      for in-flight packet modifications and is not relevant for direct
+      exporting.
+
+   Reserved:
+      This field MUST be ignored by the receiver.
+
+   Optional fields:
+      The optional fields, if present, reside after the Reserved field.
+      The order of the optional fields is according to the order of the
+      respective bits, starting from the most significant bit, that are
+      enabled in the Extension-Flags field.  Each optional field is 4
+      octets long.
+
+      Flow ID:
+         An optional 32-bit field representing the flow identifier.  If
+         the actual Flow ID is shorter than 32 bits, it is zero padded
+         in its most significant bits.  The field is set at the
+         encapsulating node.  The Flow ID can be used to correlate the
+         exported data of the same flow from multiple nodes and from
+         multiple packets.  Flow ID values are expected to be allocated
+         in a way that avoids collisions.  For example, random
+         assignment of Flow ID values can be subject to collisions,
+         while centralized allocation can avoid this problem.  The
+         specification of the Flow ID allocation method is not within
+         the scope of this document.
+
+      Sequence Number:
+         An optional 32-bit sequence number starting from 0 and
+         incremented by 1 for each packet from the same flow at the
+         encapsulating node that includes the DEX option.  The Sequence
+         Number, when combined with the Flow ID, provides a convenient
+         approach to correlate the exported data from the same user
+         packet.
+
+4.  IANA Considerations
+
+4.1.  IOAM Type
+
+   The "IOAM Option-Type" registry is defined in Section 7.1 of
+   [RFC9197].  IANA has allocated the following code point from the
+   "IOAM Option-Type" registry as follows:
+
+   Code Point:  4
+
+   Name  IOAM Direct Export (DEX) Option-Type
+
+   Description:  Direct exporting
+
+   Reference:  This document
+
+4.2.  IOAM DEX Flags
+
+   IANA has created the "IOAM DEX Flags" registry.  This registry
+   includes 8 flag bits.  Allocation is based on the "IETF Review"
+   procedure defined in [RFC8126].
+
+   New registration requests MUST use the following template:
+
+   Bit:  Desired bit to be allocated in the 8-bit Flags field of the DEX
+      Option-Type.
+
+   Description:  Brief description of the newly registered bit.
+
+   Reference:  Reference to the document that defines the new bit.
+
+4.3.  IOAM DEX Extension-Flags
+
+   IANA has created the "IOAM DEX Extension-Flags" registry.  This
+   registry includes 8 flag bits.  Bit 0 (the most significant bit) and
+   bit 1 in the registry are allocated by this document and described in
+   Section 3.2.  Allocation of the other bits should be performed based
+   on the "IETF Review" procedure defined in [RFC8126].
+
+   Bit 0:  "Flow ID [RFC9326]"
+
+   Bit 1:  "Sequence Number [RFC9326]"
+
+   New registration requests MUST use the following template:
+
+   Bit:  Desired bit to be allocated in the 8-bit Extension-Flags field
+      of the DEX Option-Type.
+
+   Description:  Brief description of the newly registered bit.
+
+   Reference:  Reference to the document that defines the new bit.
+
+5.  Performance Considerations
+
+   The DEX Option-Type triggers IOAM data to be collected and/or
+   exported packets to be exported to a receiving entity (or entities).
+   In some cases, this may impact the receiving entity's performance or
+   the performance along the paths leading to it.
+
+   Therefore, the performance impact of these exported packets is
+   limited by taking two measures: at the encapsulating nodes by
+   selective DEX encapsulation (Section 3.1.1) and at the transit nodes
+   by limiting exporting rate (Section 3.1.2).  These two measures
+   ensure that direct exporting is used at a rate that does not
+   significantly affect the network bandwidth and does not overload the
+   receiving entity.  Moreover, it is possible to load balance the
+   exported data among multiple receiving entities, although the
+   exporting method is not within the scope of this document.
+
+   It should be noted that, in some networks, DEX data may be exported
+   over an out-of-band network in which a large volume of exported
+   traffic does not compromise user traffic.  In this case, an operator
+   may choose to disable the exporting rate limiting.
+
+6.  Security Considerations
+
+   The security considerations of IOAM in general are discussed in
+   [RFC9197].  Specifically, an attacker may try to use the
+   functionality that is defined in this document to attack the network.
+
+   An attacker may attempt to overload network devices by injecting
+   synthetic packets that include the DEX Option-Type.  Similarly, an
+   on-path attacker may maliciously incorporate the DEX Option-Type into
+   transit packets or maliciously remove it from packets in which it is
+   incorporated.
+
+   Forcing DEX, either in synthetic packets or in transit packets, may
+   overload the IOAM nodes and/or the receiving entity (or entities).
+   Since this mechanism affects multiple devices along the network path,
+   it potentially amplifies the effect on the network bandwidth, the
+   storage of the devices that collect the data, and the receiving
+   entity's load.
+
+   The amplification effect of DEX may be worse in wide area networks in
+   which there are multiple IOAM-Domains.  For example, if DEX is used
+   in IOAM-Domain 1 for exporting IOAM data to a receiving entity, then
+   the exported packets of IOAM-Domain 1 can be forwarded through IOAM-
+   Domain 2, in which they are subject to DEX.  In turn, the exported
+   packets of IOAM-Domain 2 may be forwarded through another IOAM domain
+   (or through IOAM-Domain 1); theoretically, this recursive
+   amplification may continue infinitely.
+
+   In order to mitigate the attacks described above, the following
+   requirements (Section 3) have been defined:
+
+   *  Selective DEX (Section 3.1.1) is applied by IOAM encapsulating
+      nodes in order to limit the potential impact of DEX attacks to a
+      small fraction of the traffic.
+
+   *  Rate limiting of exported traffic (Section 3.1.2) is applied by
+      IOAM nodes in order to prevent overloading attacks and to
+      significantly limit the scale of amplification attacks.
+
+   *  IOAM encapsulating nodes are required to avoid pushing the DEX
+      Option-Type into IOAM exported packets (Section 3.1.2), thus
+      preventing some of the amplification and export loop scenarios.
+
+   Although the exporting method is not within the scope of this
+   document, any exporting method MUST secure the exported data from the
+   IOAM node to the receiving entity in order to protect the
+   confidentiality and guarantee the integrity of the exported data.
+   Specifically, an IOAM node that performs DEX exporting MUST send the
+   exported data to a pre-configured trusted receiving entity that is in
+   the same IOAM-Domain as the exporting IOAM node.  Furthermore, an
+   IOAM node MUST gain explicit consent to export data to a receiving
+   entity before starting to send exported data.
+
+   An attacker may keep track of the information sent in DEX headers as
+   a means of reconnaissance.  This form of recon can be mitigated to
+   some extent by careful allocation of the Flow ID and Sequence Number
+   space in a way that does not compromise privacy aspects, such as
+   customer identities.
+
+   The integrity of the DEX Option-Type can be protected through a
+   mechanism of the encapsulating protocol.  While [IOAM-DATA-INTEGRITY]
+   introduces an integrity protection mechanism that protects the
+   integrity of IOAM-Data-Fields, the DEX Option-Type does not include
+   IOAM-Data-Fields; therefore, these integrity protection mechanisms
+   are not applicable to the DEX Option-Type.  As discussed in the
+   threat analysis of [IOAM-DATA-INTEGRITY], injection or modification
+   of IOAM-Option-Type headers are threats that are not addressed in
+   IOAM.
+
+   IOAM is assumed to be deployed in a restricted administrative domain,
+   thus limiting the scope of the threats above and their effect.  This
+   is a fundamental assumption with respect to the security aspects of
+   IOAM, as further discussed in [RFC9197].
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC9197]  Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi,
+              Ed., "Data Fields for In Situ Operations, Administration,
+              and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197,
+              May 2022, <https://www.rfc-editor.org/info/rfc9197>.
+
+7.2.  Informative References
+
+   [IOAM-DATA-INTEGRITY]
+              Brockners, F., Bhandari, S., Mizrahi, T., and J. Iurman,
+              "Integrity of In-situ OAM Data Fields", Work in Progress,
+              Internet-Draft, draft-ietf-ippm-ioam-data-integrity-02, 5
+              July 2022, <https://datatracker.ietf.org/doc/html/draft-
+              ietf-ippm-ioam-data-integrity-02>.
+
+   [IOAM-IPV6-OPTIONS]
+              Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
+              Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
+              ipv6-options-09, 11 October 2022,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
+              ioam-ipv6-options-09>.
+
+   [IOAM-RAWEXPORT]
+              Spiegel, M., Brockners, F., Bhandari, S., and R.
+              Sivakolundu, "In-situ OAM raw data export with IPFIX",
+              Work in Progress, Internet-Draft, draft-spiegel-ippm-ioam-
+              rawexport-06, 21 February 2022,
+              <https://datatracker.ietf.org/doc/html/draft-spiegel-ippm-
+              ioam-rawexport-06>.
+
+   [POSTCARD-BASED-TELEMETRY]
+              Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
+              T., Li, Z., Graf, T., Mishra, G. S., Shin, J., and K. Lee,
+              "Marking-based Direct Export for On-path Telemetry", Work
+              in Progress, Internet-Draft, draft-song-ippm-postcard-
+              based-telemetry-14, 7 September 2022,
+              <https://datatracker.ietf.org/doc/html/draft-song-ippm-
+              postcard-based-telemetry-14>.
+
+   [RFC5475]  Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
+              Raspall, "Sampling and Filtering Techniques for IP Packet
+              Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009,
+              <https://www.rfc-editor.org/info/rfc5475>.
+
+   [RFC6291]  Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
+              D., and S. Mansfield, "Guidelines for the Use of the "OAM"
+              Acronym in the IETF", BCP 161, RFC 6291,
+              DOI 10.17487/RFC6291, June 2011,
+              <https://www.rfc-editor.org/info/rfc6291>.
+
+   [RFC7014]  D'Antonio, S., Zseby, T., Henke, C., and L. Peluso, "Flow
+              Selection Techniques", RFC 7014, DOI 10.17487/RFC7014,
+              September 2013, <https://www.rfc-editor.org/info/rfc7014>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC9322]  Mizrahi, T., Brockners, F., Bhandari, S., Gafni, B., and
+              M. Spiegel, "In Situ Operations, Administration, and
+              Maintanence (IOAM) Loopback and Active Flags", RFC 9322,
+              DOI 10.17487/RFC9322, November 2022,
+              <https://www.rfc-editor.org/info/rfc9322>.
+
+Appendix A.  Notes about the History of This Document
+
+   This document evolved from combining some of the concepts of PBT-I
+   from [POSTCARD-BASED-TELEMETRY] with immediate exporting from early
+   versions of [RFC9322].
+
+   In order to help correlate and order the exported packets, it is
+   possible to include the Hop_Lim/Node_ID IOAM-Data-Field in exported
+   packets.  If the IOAM-Trace-Type [RFC9197] has the Hop_Lim/Node_ID
+   bit set, then exported packets include the Hop_Lim/Node_ID IOAM-Data-
+   Field, which contains the TTL/Hop Limit value from a lower layer
+   protocol.  An alternative approach was considered during the design
+   of this document, according to which a 1-octet Hop Count field would
+   be included in the DEX header (presumably by claiming some space from
+   the Flags field).  The Hop Limit would start from 0 at the
+   encapsulating node and be incremented by each IOAM transit node that
+   supports the DEX Option-Type.  In this approach, the Hop Count field
+   value would also be included in the exported packet.
+
+Acknowledgments
+
+   The authors thank Martin Duke, Tommy Pauly, Meral Shirazipour, Colin
+   Perkins, Stephen Farrell, Linda Dunbar, Justin Iurman, Greg Mirsky,
+   and other members of the IPPM working group for many helpful
+   comments.
+
+Contributors
+
+   The Editors would like to recognize the contributions of the
+   following individuals to this document.
+
+   Tianran Zhou
+   Huawei
+   156 Beiqing Rd.
+   Beijing
+   100095
+   China
+   Email: zhoutianran@huawei.com
+
+
+   Zhenbin Li
+   Huawei
+   156 Beiqing Rd.
+   Beijing
+   100095
+   China
+   Email: lizhenbin@huawei.com
+
+
+   Ramesh Sivakolundu
+   Cisco Systems, Inc.
+   170 West Tasman Dr.
+   San Jose, CA 95134
+   United States of America
+   Email: sramesh@cisco.com
+
+
+Authors' Addresses
+
+   Haoyu Song
+   Futurewei
+   2330 Central Expressway
+   Santa Clara,  95050
+   United States of America
+   Email: haoyu.song@futurewei.com
+
+
+   Barak Gafni
+   Nvidia
+   Suite 100
+   350 Oakmead Parkway
+   Sunnyvale, CA 94085
+   United States of America
+   Email: gbarak@nvidia.com
+
+
+   Frank Brockners
+   Cisco Systems, Inc.
+   Hansaallee 249
+   40549 Duesseldorf
+   Germany
+   Email: fbrockne@cisco.com
+
+
+   Shwetha Bhandari
+   Thoughtspot
+   3rd Floor, Indiqube Orion, Garden Layout, HSR Layout
+   24th Main Rd
+   Bangalore 560 102
+   Karnataka
+   India
+   Email: shwetha.bhandari@thoughtspot.com
+
+
+   Tal Mizrahi
+   Huawei
+   8-2 Matam
+   Haifa 3190501
+   Israel
+   Email: tal.mizrahi.phd@gmail.com