Internet DRAFT - draft-gandhi-ippm-stamp-ioam
draft-gandhi-ippm-stamp-ioam
IPPM Working Group R. Gandhi, Ed.
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track 16 August 2023
Expires: 17 February 2024
Simple TWAMP (STAMP) Extensions for Hop-By-Hop and Edge-To-Edge
Measurements
draft-gandhi-ippm-stamp-ioam-00
Abstract
Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC
8762 and its optional extensions defined in RFC 8972 can be used for
Edge-To-Edge (E2E) active measurement. In Situ Operations,
Administration, and Maintenance (IOAM) data fields defined in RFC
9197 and RFC 9326 can be used for recording and collecting Hop-By-Hop
(HBH) and E2E operational and telemetry information. This document
extends STAMP to carry IOAM data fields for HBH and E2E two-way
active measurement and telemetry. The STAMP extensions are generic
and allow to carry and reflect any type of IPv6 option and MPLS
Network Action Sub-Stacks for two-way active measurement.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 17 February 2024.
Copyright Notice
Copyright (c) 2023 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.
Gandhi Expires 17 February 2024 [Page 1]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
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
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.3. STAMP Reference Topology . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IPv6 Data plane . . . . . . . . . . . . . . . . . . . . . 5
3.2. MPLS Data plane . . . . . . . . . . . . . . . . . . . . . 6
4. STAMP Extensions . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Reflected IPv6 Option Data TLV . . . . . . . . . . . . . 8
4.2. Reflected MNA Sub-Stack Data TLV . . . . . . . . . . . . 8
5. Generic Applicability . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The Simple Two-Way Active Measurement Protocol (STAMP) provides
capabilities for the measurement of various performance metrics in IP
networks [RFC8762] without the use of a control channel to pre-signal
session parameters. [RFC8972] defines optional extensions, in the
form of TLVs, for STAMP. The STAMP test packets are transmitted
along a path between a Session-Sender and a Session-Reflector to
measure Edge-To-Edge (E2E) performance delay and packet loss along
that path.
In Situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information
while the packet traverses a path between two points in the network.
The term "in-situ" refers to the fact that the IOAM data fields are
added to the data packets rather than being sent within the probe
packets specifically dedicated to OAM. The IOAM data fields are
defined in [RFC9197]. The IOAM data fields are further updated in
[RFC9326] for direct export use-cases. Examples of data recorded by
IOAM Trace Options includes per-hop information, e.g., node ID,
Gandhi Expires 17 February 2024 [Page 2]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
timestamp, queue depth, interface ID, interface load, etc. The
information collected can be used, for example, monitoring ECMP
paths, proof-of-transit (POT) and troubleshooting failures in the
network. Currently there is no accepted method defined to send the
collected IOAM data fields back to the Sender where the Sender can
use that information to support the IOAM use-cases. In addition,
there is a limit on how large the IOAM data fields can be added in
the packet header such that the hardware with limited capability for
read and write depth can still process the IOAM data fields.
IPv6 packets can carry IPv6 options of Hop-By-Hop (HBH) and
Destination types as defined in [RFC8200].
[I-D.ietf-ippm-ioam-ipv6-options] defines types for HBH and
destination options to carry various IOAM data fields for IPv6 data
plane.
MPLS packets can carry MPLS Network Action (MNA) Sub-Stack as defined
in [I-D.ietf-mpls-mna-hdr]. [I-D.gandhi-mpls-ioam] defines
extensions to carry various IOAM data fields for MPLS data plane.
It may be desired to record and collect HBH and E2E operational and
telemetry information using two-way active measurement packets
between two nodes in a network. This is achieved by extending the
STAMP [RFC8762] to carry extension headers with IOAM data fields and
by augmenting the optional STAMP extensions defined in [RFC8972] to
reflect them as specified in this document. The procedure leverages
the implementation of IOAM data fields on the midpoint nodes with
IPv6 and MPLS data planes without any additional requirements.
The procedure and STAMP extensions defined in this document are
generic and allow to carry any IPv6 options and MPLS Network Action
Sub-Stacks in Session-Sender test packets and reflect them in
Session-Reflector test packets for HBH and E2E two-way active
measurement.
2. Conventions Used in This Document
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.
Gandhi Expires 17 February 2024 [Page 3]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
2.2. Abbreviations
AMM: Alternate Marking Method
ECMP: Equal Cost Multi-Path
E2E: Edge-To-Edge
HBH: Hop-By-Hop
IOAM: In Situ Operations, Administration, and Maintenance
MPLS: Multiprotocol Label Switching
MNA: MPLS Network Action
OAM: Operations, Administration, and Maintenance
STAMP: Simple Two-way Active Measurement Protocol.
2.3. STAMP Reference Topology
In the "STAMP Reference Topology" shown in Figure 1, the STAMP
Session-Sender S1 initiates a Session-Sender test packet and the
STAMP Session-Reflector R1 transmits a reply Session-Reflector test
packet. The T1 is a transmit timestamp and T4 is a receive
timestamp, both added by node S1. The T2 is a receive timestamp and
T3 is a transmit timestamp, both added by node R1. Node M1 is a
midpoint node that does not perform any STAMP processing.
T1 T2
/ \
+-------+ Test Packet +-------+ +-------+
| | - - - - - - - - | | - - - - - - - - ->| |
| S1 |=================| M1 |===================| R1 |
| |<- - - - - - - - | | - - - - - - - - - | |
+-------+ +-------+ Reply Test Packet +-------+
\ /
T4 T3
STAMP Session-Sender STAMP Session-Reflector
Figure 1: STAMP Reference Topology
Gandhi Expires 17 February 2024 [Page 4]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
3. Overview
[RFC8972] defines optional extensions for STAMP. The optional
extensions are added in base STAMP test packet defined in [RFC8762]
in the form of TLVs. As specified in [RFC8972], both Session-Sender
and Session-Reflector test packets are symmetric in size when
including all optional TLVs. Session-Reflector reflects all received
STAMP TLVs from the Session-Sender test packets.
3.1. IPv6 Data plane
[I-D.ietf-ippm-ioam-ipv6-options] defines types for HBH and
destination options to carry the IOAM option-types defined in
[RFC9197] and [RFC9326] for IPv6 data plane. The STAMP Session-
Sender and Session-Reflector test packets carry these IPv6 options
with IOAM option-types for recording and collecting HBH and E2E
operational and telemetry information for two-way active measurement
as shown in Figure 2. The Session-Sender, midpoints, and Session-
Reflector nodes process the IOAM data fields as defined in
[I-D.ietf-ippm-ioam-ipv6-options].
This document defines a new TLV option for STAMP, called "Reflected
IPv6 Option Data" (value TBA1). When a STAMP Session-Sender adds an
IPv6 option in IPv6 header for IOAM defined in
[I-D.ietf-ippm-ioam-ipv6-options], it also adds "Reflected IPv6
Option Data" STAMP TLV in the Session-Sender test packet with size of
the IPv6 option length including IPv6 option header bytes and the
value field in the TLV initialized to zeros. When adding multiple
IPv6 options in the Session-Sender test packet, multiple "Reflected
IPv6 Option Data" TLVs MUST be added, each one with matching length
with the IPv6 option and in the same order.
+-------------------------------------+
| IPv6 Header |
+-------------------------------------+
| HBH IOAM IPv6 Option RFC 9197, 9326 |
+-------------------------------------+
| UDP Header |
+-------------------------------------+
| STAMP Packet RFC 8972 |
+-------------------------------------+
| IPv6 Option Data STAMP TLV (TBA1) |
+-------------------------------------+
Figure 2: Example STAMP Test Packet with Reflected IPv6 Option
Data TLV
Gandhi Expires 17 February 2024 [Page 5]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
When Session-Reflector receives STAMP test packet with IPv6 option
and STAMP TLV of "Reflected IPv6 Option Data", the Session-Reflector
that supports this STAMP TLV, MUST copy the entire IPv6 option
including the header into the STAMP "Reflected IPv6 Option Data" TLV
in Session-Reflector payload. The Session-Reflector also MUST add
the matching IPv6 option in the IPv6 header of the Session-Reflector
test packet for the reverse direction for two-way measurement. When
there are multiple IPv6 options in the Session-Sender test packet,
all IPv6 options MUST be copied in the STAMP "Reflected IPv6 Option
Data" TLVs and MUST add all IPv6 options in the IPv6 header of the
Session-Reflector test packet and in the same order.
When Session-Reflector received STAMP test packet with IPv6 option
but it does not carry STAMP TLV of "Reflected IPv6 Option Data", the
Session-Reflector does not copy the IPv6 option into the Session-
Reflector test packet.
Note that the use-case where the IPv6 option length changes in the
packet along the path is outside the scope of this document.
Note that use-case where IPv6 options are added or removed in the
packet along the path is outside the scope of this document.
3.2. MPLS Data plane
[I-D.ietf-mpls-mna-hdr] defines MPLS Network Action (MNA) Sub-Stack
to carry various Network Actions with Ancillary data.
[I-D.gandhi-mpls-ioam] defines extensions using MNA to carry various
IOAM data fields for MPLS data plane. The STAMP Session-Sender and
Session-Reflector test packets carry the MNA Sub-Stack with IOAM
option-types for recording and collecting HBH and E2E operational and
telemetry information for two-way active measurement as shown in
Figure 3. The Session-Sender, midpoints, and Session-Reflector nodes
process the IOAM data fields as defined in [I-D.gandhi-mpls-ioam].
This document also defines a new TLV option for STAMP, called
"Reflected MNA Sub-Stack Data" (value TBA2). When a STAMP Session-
Sender adds an MNA Sub-Stack in the test packet, it also adds
"Reflected MNA Sub-Stack Data" STAMP TLV in the Session-Sender test
packet with size of the MNA Sub-Stack length (NASL) including In-
Stack Ancillary Data (ISD) and Post-Stack Ancillary Data (PSD) and
MNA header and the value field in the TLV initialized to zeros. When
adding multiple MNA Sub Stacks in the Session-Sender test packet,
multiple "Reflected MNA Sub-Stack Data" TLVs MUST be added, each one
with matching length with the MNA Sub-Stack and Ancillary Data and in
the same order.
Gandhi Expires 17 February 2024 [Page 6]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
+---------------------------------------+
| MPLS Header |
+---------------------------------------+
| HBH IOAM MNA Sub-Stack RFC 9197, 9326 |
+---------------------------------------+
| IP Header |
+---------------------------------------+
| UDP Header |
+---------------------------------------+
| STAMP Packet RFC 8972 |
+---------------------------------------+
| MNA Sub-Stack Data STAMP TLV (TBA2) |
+---------------------------------------+
Figure 3: Example STAMP Test Packet with Reflected MNA Sub-Stack
Data TLV
When Session-Reflector receives STAMP test packet with MNA and STAMP
TLV of "Reflected MNA Sub-Stack Data", the Session-Reflector that
supports this STAMP TLV, MUST copy the entire MNA Sub-Stack,
Ancillary Data including the header into the "Reflected MNA Sub-Stack
Data" TLV in Session-Reflector payload. The Session-Reflector also
MUST add the matching MNA Sub-Stacks and Ancillary Data in the MPLS
header of the Session-Reflector test packet for the reverse direction
for two-way measurement. When there are multiple MNA Sub-Stacks in
the Session-Sender test packet, all MNA Sub-Stacks including
Ancillary Data MUST be copied in the STAMP TLVs and MUST add all MNA
Sub-Stacks including Ancillary Data in the Session-Reflector test
packet and in the same order.
When Session-Reflector received STAMP test packet with MNA Sub-Stack
but it does not carry STAMP TLV of "Reflected MNA Sub-Stack Data",
the Session-Reflector does not copy the MNA Sub-Stack into the
Session-Reflector test packet.
Note that the use-case where the MNA Sub-Stack length changes in the
packet along the path is outside the scope of this document.
Note that use-case where MNA Sub-Stacks are added or removed in the
packet along the path is outside the scope of this document.
4. STAMP Extensions
Gandhi Expires 17 February 2024 [Page 7]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
4.1. Reflected IPv6 Option Data TLV
The Reflected IPv6 Option Data STAMP TLV is carried by Session-Sender
and Session-Reflector test packets. STAMP test packets may carry
multiple TLVs of this type. The same Reflected IPv6 Option Data
STAMP TLV is used for reflecting both HBH and Destination IPv6
options. The format of the Reflected IPv6 Option Data TLV is shown
in Figure 4.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBA1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected IPv6 Option Data |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Reflected IPv6 Option Data TLV
The TLV fields are defined as follows:
Type : Type (value TBA1)
STAMP TLV Flags : The STAMP TLV Flags follow the procedures described
in [RFC8972].
Length : A two-octet field equal to the length of the Data in octets.
The Session-Reflector MUST return an error in STAMP TLV Flags when it
determines that the length of the TLV does not match the length of
the corresponding IPv6 option when processing in the same order as
IPv6 options in the IPv6 header.
4.2. Reflected MNA Sub-Stack Data TLV
The Reflected MNA Sub-Stack Data STAMP TLV is carried by Session-
Sender and Session-Reflector test packets. STAMP test packets may
carry multiple TLVs of this type. The format of the Reflected MNA
Sub-Stack Data TLV is shown in Figure 5.
Gandhi Expires 17 February 2024 [Page 8]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags| Type=TBA2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reflected MNA Sub-Stack Data |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Reflected MNA Sub-Stack Data TLV
The TLV fields are defined as follows:
Type : Type (value TBA2)
STAMP TLV Flags : The STAMP TLV Flags follow the procedures described
in [RFC8972].
Length : A two-octet field equal to the length of the Data in octets.
The Session-Reflector MUST return an error in STAMP TLV Flags when it
determines that the length of the TLV does not match the length of
the corresponding MNA Sub-Stack when processing in the same order as
MNA Sub-Stacks in the MPLS header.
5. Generic Applicability
The procedure and extensions defined in this document for STAMP for
IPv6 data plane are generic and can be used by Session-Sender and
Session-Reflector test packets to reflect any IPv6 option (not just
limited to the IPv6 options with IOAM data fields) for HBH and E2E
two-way active measurement as shown in Figure 6. For example, using
the Alternate Marking Method (AMM) IPv6 destination option defined in
RFC 9343, Performance and Diagnostic Metrics (PDM) IPv6 option
defined in RFC 8250, Maximum Path MTU IPv6 option defined in RFC
9268, and any other IPv6 option that may be defined in future.
Gandhi Expires 17 February 2024 [Page 9]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
+------------------------------------+
| IPv6 Header |
+------------------------------------+
| IPv6 Option1 RFC 8200 |
+------------------------------------+
| IPv6 Option2 RFC 8200 |
+------------------------------------+
| IPv6 Option3 RFC 8200 |
+------------------------------------+
| UDP Header |
+------------------------------------+
| STAMP Packet RFC 8972 |
+------------------------------------+
| IPv6 Option1 Data STAMP TLV (TBA1) |
+------------------------------------+
| IPv6 Option2 Data STAMP TLV (TBA1) |
+------------------------------------+
| IPv6 Option3 Data STAMP TLV (TBA1) |
+------------------------------------+
Figure 6: Example STAMP Test Packet with Generic Reflected IPv6
Option Data
The procedure and extensions defined in this document for STAMP for
MPLS data plane are generic and can be used by Session-Sender and
Session-Reflector test packets to reflect any MNA Sub-Stack for HBH
and E2E two-way active measurement as shown in Figure 7.
Gandhi Expires 17 February 2024 [Page 10]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
+--------------------------------------+
| MPLS Header |
+--------------------------------------+
| MNA Sub-Stack1 I-D.ietf-mpls-mna-hdr |
+--------------------------------------+
| MNA Sub-Stack2 I-D.ietf-mpls-mna-hdr |
+--------------------------------------+
| MNA Sub-Stack3 I-D.ietf-mpls-mna-hdr |
+--------------------------------------+
| IP Header |
+--------------------------------------+
| UDP Header |
+--------------------------------------+
| STAMP Packet RFC 8972 |
+--------------------------------------+
| MNA Sub-Stack1 Data STAMP TLV (TBA2) |
+--------------------------------------+
| MNA Sub-Stack2 Data STAMP TLV (TBA2) |
+--------------------------------------+
| MNA Sub-Stack3 Data STAMP TLV (TBA2) |
+--------------------------------------+
Figure 7: Example STAMP Test Packet with Generic Reflected MNA
Sub-Stack Data
6. Security Considerations
The security considerations specified in [RFC8762], [RFC8972],
[RFC8200], [RFC9197], and [RFC9326] also apply to the procedure and
extensions defined in this document.
7. IANA Considerations
IANA has created the "STAMP TLV Types" registry for [RFC8972]. IANA
is requested to allocate a value for the "Reflected IPv6 Option Data"
TLV Type and a value for the "Reflected MNA Sub-Stack Data" TLV Type
from the IETF Review TLV range of the same registry.
+=======+==============================+===============+
| Value | Description | Reference |
+=======+==============================+===============+
| TBA1 | Reflected IPv6 Option Data | This document |
+-------+------------------------------+---------------+
| TBA2 | Reflected MNA Sub-Stack Data | This document |
+-------+------------------------------+---------------+
Table 1: STAMP TLV Types
Gandhi Expires 17 February 2024 [Page 11]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
8. References
8.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>.
[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
Two-Way Active Measurement Protocol", RFC 8762,
DOI 10.17487/RFC8762, March 2020,
<https://www.rfc-editor.org/info/rfc8762>.
[RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A.,
and E. Ruffini, "Simple Two-Way Active Measurement
Protocol Optional Extensions", RFC 8972,
DOI 10.17487/RFC8972, January 2021,
<https://www.rfc-editor.org/info/rfc8972>.
8.2. Informative References
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[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>.
[RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T.
Mizrahi, "In Situ Operations, Administration, and
Maintenance (IOAM) Direct Exporting", RFC 9326,
DOI 10.17487/RFC9326, November 2022,
<https://www.rfc-editor.org/info/rfc9326>.
[I-D.ietf-ippm-ioam-ipv6-options]
Bhandari, S. and F. Brockners, "In-situ OAM IPv6 Options",
Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-
ipv6-options-12, 7 May 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-
ioam-ipv6-options-12>.
Gandhi Expires 17 February 2024 [Page 12]
Internet-Draft STAMP for HBH and E2E Measurements August 2023
[I-D.ietf-mpls-mna-hdr]
Rajamanickam, J., Gandhi, R., Zigler, R., Song, H., and K.
Kompella, "MPLS Network Action (MNA) Sub-Stack Solution",
Work in Progress, Internet-Draft, draft-ietf-mpls-mna-hdr-
02, 29 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-mpls-mna-hdr-02>.
[I-D.gandhi-mpls-ioam]
Gandhi, R., Brockners, F., Wen, B., Decraene, B., and H.
Song, "MPLS Data Plane Encapsulation for In Situ OAM
Data", Work in Progress, Internet-Draft, draft-gandhi-
mpls-ioam-10, 10 March 2023,
<https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-
ioam-10>.
Acknowledgments
TBA
Author's Address
Rakesh Gandhi (editor)
Cisco Systems, Inc.
Canada
Email: rgandhi@cisco.com
Gandhi Expires 17 February 2024 [Page 13]
