<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" ipr="trust200902" docName="draft-ietf-nvo3-geneve-oam-16" number="9772" consensus="true" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" prepTime="2025-05-31T17:41:02" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve-oam-16" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9772" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Active OAM for Use in Geneve">Active Operations, Administration, and Maintenance (OAM) for Use in Generic Network Virtualization Encapsulation (Geneve)</title>
    <seriesInfo name="RFC" value="9772" stream="IETF"/>
    <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <email>gregimirsky@gmail.com</email>
      </address>
    </author>
    <author initials="S." surname="Boutros" fullname="Sami Boutros">
      <organization showOnFrontPage="true">Ciena</organization>
      <address>
        <email>sboutros@ciena.com</email>
      </address>
    </author>
    <author initials="D." surname="Black" fullname="David Black">
      <organization showOnFrontPage="true">Dell</organization>
      <address>
        <email>david.black@dell.com</email>
      </address>
    </author>
    <author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti">
      <organization showOnFrontPage="true">VMware</organization>
      <address>
        <email>santosh.pallagatti@gmail.com</email>
      </address>
    </author>
    <date month="05" year="2025"/>
    <area>RTG</area>
    <workgroup>nvo3</workgroup>
    <keyword>OAM</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensible network virtualization overlay protocol
designed to encapsulate network packets for transport across underlying physical networks.
This document specifies the requirements and provides a framework for Operations, Administration, and Maintenance (OAM) in Geneve networks.
It outlines the OAM functions necessary to monitor, diagnose, and troubleshoot Geneve overlay networks to ensure
proper operation and performance. The document aims to guide the implementation of OAM mechanisms within the Geneve protocol
to support network operators in maintaining reliable and efficient virtualized network environments.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            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.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9772" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) 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.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2.1.2">
                  <li pn="section-toc.1-1.1.2.1.2.1">
                    <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.2.1.1"><xref derivedContent="1.1.1" format="counter" sectionFormat="of" target="section-1.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
                  </li>
                  <li pn="section-toc.1-1.1.2.1.2.2">
                    <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.2.2.1"><xref derivedContent="1.1.2" format="counter" sectionFormat="of" target="section-1.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acronyms">Acronyms</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-applicability-of-active">The Applicability of Active OAM Protocols in Geneve Networks</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t indent="0" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-for-active-oam">Requirements for Active OAM Protocols in Geneve Networks</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t indent="0" pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-defect-detection-and-troubl">Defect Detection and Troubleshooting in Geneve Network with Active OAM</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2.2.2">
                  <li pn="section-toc.1-1.2.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.2.2.2.2.1.1"><xref derivedContent="2.2.1" format="counter" sectionFormat="of" target="section-2.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-echo-request-and-echo-reply">Echo Request and Echo Reply in Geneve Tunnel</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t indent="0" pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-active-oam-encapsulation-in">Active OAM Encapsulation in Geneve</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
 Geneve <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/> is designed to support various scenarios of network virtualization.
 It encapsulates multiple protocols, such as Ethernet and IPv4/IPv6, and includes metadata within the Geneve message.
      </t>
      <t indent="0" pn="section-1-2">
 Operations, Administration, and Maintenance (OAM) protocols provide fault management and performance monitoring functions
 necessary for comprehensive network operation. Active OAM protocols, as defined in <xref target="RFC7799" format="default" sectionFormat="of" derivedContent="RFC7799"/>,
 utilize specially constructed packets injected into the network. OAM protocols such as ICMP and ICMPv6 (<xref target="RFC0792" format="default" sectionFormat="of" derivedContent="RFC0792"/> and
 <xref target="RFC4443" format="default" sectionFormat="of" derivedContent="RFC4443"/> respectively), Bidirectional Forwarding Detection (BFD) <xref target="RFC5880" format="default" sectionFormat="of" derivedContent="RFC5880"/>, and the 
 Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762" format="default" sectionFormat="of" derivedContent="RFC8762"/> are examples of active OAM protocols.
 To ensure that performance metrics or detected failures
 are accurately related to a particular Geneve flow, it is critical that these OAM test packets share fate, i.e., are in-band, with the overlay data packets
 of that monitored flow when traversing the underlay network. In this document, "in-band OAM" is interpreted as follows:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-3">
        <li pn="section-1-3.1">
             In-band OAM is an active or hybrid OAM method, as defined in <xref target="RFC7799" format="default" sectionFormat="of" derivedContent="RFC7799"/>,
             that traverses the same set of links and interfaces and receives the same Quality of Service
             treatment as the monitored object. In this context, the monitored object refers to either
             the entire Geneve tunnel or a specific tenant flow within a given Geneve tunnel.
</li>
      </ul>
      <t indent="0" pn="section-1-4">
<xref target="requirements" format="default" sectionFormat="of" derivedContent="Section 2.1"/> lists the general requirements for active OAM protocols in the Geneve overlay network.
 IP encapsulation meets these requirements and is suitable for encapsulating active OAM protocols within a Geneve overlay network.
   Active OAM messages in a
   Geneve overlay network are exchanged between two Geneve tunnel
   endpoints; each endpoint may be the tenant-facing interface of the Network
   Virtualization Edge (NVE) or another device acting as a Geneve tunnel
   endpoint.
Testing end-to-end between tenants is out of scope.
 For simplicity, this document uses an NVE to represent the Geneve tunnel endpoint.
 Refer to <xref target="RFC7365" format="default" sectionFormat="of" derivedContent="RFC7365"/> and <xref target="RFC8014" format="default" sectionFormat="of" derivedContent="RFC8014"/> for detailed definitions and descriptions of an NVE.
      </t>
      <t indent="0" pn="section-1-5">
 The IP encapsulation of Geneve OAM defined in this document applies to an overlay service by introducing
 a Management Virtual Network Identifier (VNI), which can be used in combination with various values
 of the Protocol Type field in the Geneve header, such as Ethertypes for IPv4 or IPv6.
 The analysis and definition of other types of OAM encapsulation in Geneve are outside the scope of this document.
      </t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1.1">
          <name slugifiedName="name-requirements-language">Requirements Language</name>
          <t indent="0" pn="section-1.1.1-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-1.1.2">
          <name slugifiedName="name-acronyms">Acronyms</name>
          <dl spacing="normal" newline="false" indent="3" pn="section-1.1.2-1">
            <dt pn="section-1.1.2-1.1">Geneve:</dt>
            <dd pn="section-1.1.2-1.2">Generic Network Virtualization Encapsulation</dd>
            <dt pn="section-1.1.2-1.3">NVO3:</dt>
            <dd pn="section-1.1.2-1.4">Network Virtualization over Layer 3</dd>
            <dt pn="section-1.1.2-1.5">OAM:</dt>
            <dd pn="section-1.1.2-1.6">Operations, Administration, and Maintenance</dd>
            <dt pn="section-1.1.2-1.7">VNI:</dt>
            <dd pn="section-1.1.2-1.8">Virtual Network Identifier</dd>
            <dt pn="section-1.1.2-1.9">BFD:</dt>
            <dd pn="section-1.1.2-1.10">Bidirectional Forwarding Detection</dd>
            <dt pn="section-1.1.2-1.11">STAMP:</dt>
            <dd pn="section-1.1.2-1.12">Simple Two-way Active Measurement Protocol</dd>
            <dt pn="section-1.1.2-1.13">NVE:</dt>
            <dd pn="section-1.1.2-1.14">Network Virtualization Edge</dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="active-oam-sec" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-the-applicability-of-active">The Applicability of Active OAM Protocols in Geneve Networks</name>
      <section anchor="requirements" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-requirements-for-active-oam">Requirements for Active OAM Protocols in Geneve Networks</name>
        <t indent="0" pn="section-2.1-1">
OAM protocols, whether part of fault management or performance monitoring, are intended to provide
reliable information that can be used to detect a failure,
identify the defect, and localize it, thus helping to identify and apply corrective actions to minimize the negative impact on service.
Several OAM protocols are used to perform these functions;
these protocols require demultiplexing at the receiving instance of Geneve.
To improve the accuracy of
the correlation between the condition experienced by the monitored Geneve tunnel and
the state of the OAM protocol, the OAM encapsulation is required
to comply with the following requirements:
</t>
        <ol type="Requirement %d:" group="reqs" start="1" indent="adaptive" spacing="normal" pn="section-2.1-2">
        <li anchor="req-1" pn="section-2.1-2.1" derivedCounter="Requirement 1:">Geneve OAM test packets <bcp14>MUST</bcp14>
        share the same fate as the data traffic of the monitored Geneve
        tunnel.  
      Specifically,
      the OAM test packets <bcp14>MUST</bcp14> be in-band with the monitored traffic
      and follow the same overlay and transport paths as packets carrying
      data payloads in the forward direction, i.e., from the ingress
      toward the egress endpoint(s) of the OAM test.
	</li>
        </ol>
        <t indent="0" pn="section-2.1-3">An OAM protocol <bcp14>MAY</bcp14> be employed to monitor an entire
	Geneve tunnel. In this case, test packets could be in-band relative to
	a subset of tenant flows transported over the Geneve tunnel. If the
	goal is to monitor the conditions experienced by the flow of a
	particular tenant, the test packets <bcp14>MUST</bcp14> be in-band
	with that specific flow within the Geneve tunnel. Both scenarios are
	discussed in detail in <xref target="control-channel-sec" format="default" sectionFormat="of" derivedContent="Section 2.2"/>.</t>
        <ol type="Requirement %d:" group="reqs" start="2" indent="adaptive" spacing="normal" pn="section-2.1-4">
        <li anchor="req-2" pn="section-2.1-4.1" derivedCounter="Requirement 2:">The encapsulation of OAM control messages and
        data packets in the underlay network <bcp14>MUST</bcp14> be
        indistinguishable.
	</li>
          <li anchor="req-3" pn="section-2.1-4.2" derivedCounter="Requirement 3:">The presence of an OAM control message in a
	Geneve packet <bcp14>MUST</bcp14> be unambiguously identifiable to
	Geneve functionality, such as at endpoints of Geneve tunnels.</li>
          <li anchor="req-4" pn="section-2.1-4.3" derivedCounter="Requirement 4:">OAM test packets <bcp14>MUST NOT</bcp14> be
        forwarded to a tenant system.</li>
        </ol>
        <t indent="0" pn="section-2.1-5">A test packet generated by an active OAM protocol, whether for
	defect detection or performance measurement, <bcp14>MUST</bcp14> be
	in-band with the tunnel or data flow being monitored, as specified in
	<xref target="req-1" format="none" sectionFormat="of" derivedContent="">Requirement 1</xref>.  In environments where multiple paths through the
	domain are available, underlay transport nodes can be programmed to
	use characteristic information to balance the load across known paths.
	It is essential that test packets follow the same route -- that is,
	traverse the same set of nodes and links as a data packet of the
	monitored flow. Therefore, the following requirement supports OAM
	packet fate-sharing with the data flow.</t>
        <ol type="Requirement %d:" group="reqs" start="5" indent="adaptive" spacing="normal" pn="section-2.1-6">
        <li anchor="req-5" pn="section-2.1-6.1" derivedCounter="Requirement 5:">There <bcp14>MUST</bcp14> be a way to encode
        entropy information into the underlay forwarding scheme so that OAM
        packets take the same data-flow paths as the transit traffic flows.</li>
        </ol>
      </section>
      <section anchor="control-channel-sec" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-defect-detection-and-troubl">Defect Detection and Troubleshooting in Geneve Network with Active OAM</name>
        <t indent="0" pn="section-2.2-1">
This section considers two scenarios where active OAM is used to detect and localize defects in a Geneve network.
<xref target="geneve-model-fig" format="default" sectionFormat="of" derivedContent="Figure 1"/> presents an example of a Geneve domain.
        </t>
        <figure anchor="geneve-model-fig" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-an-example-of-a-geneve-doma">An Example of a Geneve Domain</name>
          <artwork name="" type="" align="left" alt="" pn="section-2.2-2.1">
+--------+                                             +--------+
| Tenant +--+                                     +----| Tenant |
| VNI 28 |  |                                     |    | VNI 35 |
+--------+  |          ................           |    +--------+
            |  +----+  .              .  +----+   |
            |  | NVE|--.              .--| NVE|   |
            +--| A  |  .              .  | B  |---+
               +----+  .              .  +----+
               /       .              .
              /        .     Geneve   .
+--------+   /         .    Network   .
| Tenant +--+          .              .
| VNI 35 |             .              .
+--------+             ................
                              |
                            +----+
                            | NVE|
                            | C  |
                            +----+
                              |
                              |
                    =====================
                      |               |
                  +--------+      +--------+
                  | Tenant |      | Tenant |
                  | VNI 28 |      | VNI 35 |
                  +--------+      +--------+
</artwork>
        </figure>
        <t indent="0" pn="section-2.2-3">
In the first case, consider when a communication problem between
Network Virtualization Edge (NVE) device A and NVE C exists.
Upon investigation, the operator discovers that the forwarding in the IP underlay network is working accordingly.
Still, the Geneve connection is unstable for all NVE A and NVE C tenants.
Detection, troubleshooting, and localization of the problem can be done regardless of the VNI value.
</t>
        <t indent="0" pn="section-2.2-4">
In the second case, traffic on VNI 35 between NVE A and NVE B has no problems,
as on VNI 28 between NVE A and NVE C. However, traffic on VNI 35 between NVE A
and NVE C experiences problems, for example, excessive packet loss.
</t>
        <t indent="0" pn="section-2.2-5">
   The first case can be detected and investigated using any VNI
   value, whether it connects tenant systems or not; however, to
   conform to <xref target="req-4" format="none" sectionFormat="of" derivedContent="">Requirement 4</xref>, OAM test packets <bcp14>SHOULD</bcp14> be transmitted
   on a VNI that doesn't have any tenants.  Such a Geneve tunnel is
   dedicated to carrying only control and management data between the
   tunnel endpoints, so it is referred to as a "Geneve control
   channel" and that VNI is referred to as the "Management VNI". A
   configured VNI <bcp14>MAY</bcp14> be used to identify the control channel, but it
   is <bcp14>RECOMMENDED</bcp14> that the default value 1 be used as the Management
   VNI. Encapsulation of test packets using the Management VNI is discussed in <xref target="oam-encap-section" format="default" sectionFormat="of" derivedContent="Section 2.3"/>.
</t>
        <t indent="0" pn="section-2.2-6">
The control channel of a Geneve tunnel <bcp14>MUST NOT</bcp14> carry tenant data.
   As no tenants are connected using the control channel, a system
   that supports this specification <bcp14>MUST NOT</bcp14> forward a packet
   received over the control channel to any tenant. A packet received
   by the system that supports this specification over the control channel <bcp14>MUST</bcp14> be forwarded if and only if it is sent
   onto the control channel of the concatenated Geneve tunnel.
   Else, it <bcp14>MUST</bcp14> be terminated locally. The
   Management VNI <bcp14>SHOULD</bcp14> be terminated on the tenant-facing side of
   the Geneve encapsulation/decapsulation functionality, not the DC-network-facing
   side (per definitions in <xref target="RFC8014" sectionFormat="of" section="4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8014#section-4" derivedContent="RFC8014"/>), so that Geneve
   encap/decap functionality is included in its scope.  This approach
   causes an active OAM packet, e.g., an ICMP echo request, to be
   decapsulated in the same fashion as any other received Geneve
   packet.  In this example, the resulting ICMP packet is handed to
   NVE's local management functionality for the processing which
   generates an ICMP echo reply.  The ICMP echo reply is encapsulated
   in Geneve (as specified in <xref target="oam-encap-section" format="default" sectionFormat="of" derivedContent="Section 2.3"/>) for forwarding it back to the
   NVE that sent the echo request.  One advantage of this approach is
   that a repeated ICMP echo request/reply test could detect an intermittent problem in
   Geneve encap/decap hardware, which would not be tested if the
   Management VNI were handled as a "special case" at the
   DC-network-facing interface.
</t>
        <t indent="0" pn="section-2.2-7">
The second case is when a test packet is transmitted using
the VNI value associated with the monitored service flow. By doing that, the test packet
experiences network treatment as the tenant's packets.
An example of the realization of that scenario is discussed in <xref target="RFC9521" format="default" sectionFormat="of" derivedContent="RFC9521"/>.
</t>
        <section anchor="geneve-echo-sec" numbered="true" toc="include" removeInRFC="false" pn="section-2.2.1">
          <name slugifiedName="name-echo-request-and-echo-reply">Echo Request and Echo Reply in Geneve Tunnel</name>
          <t indent="0" pn="section-2.2.1-1">
 ICMP and ICMPv6 (<xref target="RFC0792" format="default" sectionFormat="of" derivedContent="RFC0792"/> and <xref target="RFC4443" format="default" sectionFormat="of" derivedContent="RFC4443"/> respectively),
 as noted above, are examples of an active OAM protocol. They
 provide required on-demand defect detection and failure localization. ICMP control messages
 immediately follow the inner IP header encapsulated in Geneve.
 ICMP extensions for Geneve networks use mechanisms defined in <xref target="RFC4884" format="default" sectionFormat="of" derivedContent="RFC4884"/>.
</t>
        </section>
      </section>
      <section anchor="oam-encap-section" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-active-oam-encapsulation-in">Active OAM Encapsulation in Geneve</name>
        <t indent="0" pn="section-2.3-1">
Active OAM over a Management VNI in the Geneve network uses an IP encapsulation.
Protocols such as BFD <xref target="RFC5880" format="default" sectionFormat="of" derivedContent="RFC5880"/> and STAMP <xref target="RFC8762" format="default" sectionFormat="of" derivedContent="RFC8762"/> use UDP transport.
The destination UDP port number in the inner UDP header (<xref target="oam-geneve-encap-fig" format="default" sectionFormat="of" derivedContent="Figure 2"/>) identifies the OAM protocol.
This approach is well-known and has been used, for example, in MPLS networks <xref target="RFC8029" format="default" sectionFormat="of" derivedContent="RFC8029"/>.
To use IP encapsulation for an active OAM protocol, the Protocol Type field of the Geneve header
<bcp14>MUST</bcp14> be set to 0x0800 (IPv4) or 0x86DD (IPv6). <xref target="RFC9521" format="default" sectionFormat="of" derivedContent="RFC9521"/> describes the use of IP encapsulation for BFD.
</t>
        <figure anchor="oam-geneve-encap-fig" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-an-example-of-geneve-ip-udp">An Example of Geneve IP/UDP Encapsulation of an Active OAM Packet</name>
          <artwork name="" type="" align="left" alt="" pn="section-2.3-2.1">
 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Outer IPvX Header                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Outer UDP Header                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                          Geneve Header                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Inner IPvX Header                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Inner UDP Header                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Active OAM Packet                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        </figure>
        <dl newline="true" spacing="normal" indent="3" pn="section-2.3-3">
          <dt pn="section-2.3-3.1">Inner IP header:</dt>
          <dd pn="section-2.3-3.2">
            <dl newline="false" spacing="normal" indent="3" pn="section-2.3-3.2.1">
              <dt pn="section-2.3-3.2.1.1">Destination IP:</dt>
              <dd pn="section-2.3-3.2.1.2">
                <t indent="0" pn="section-2.3-3.2.1.2.1">The IP address <bcp14>MUST</bcp14> be set to the
  loopback address 127.0.0.1/32 for IPv4 version.  For IPv6, the address
  <bcp14>MUST</bcp14> be selected from the Dummy IPv6 Prefix 100:0:0:1::/64
  <xref target="RFC9780" format="default" sectionFormat="of" derivedContent="RFC9780"/>.  A source-only IPv6 address is used as the
  destination to generate an exception and a reply message to the request
  message received.</t>
              </dd>
              <dt pn="section-2.3-3.2.1.3">Source IP:</dt>
              <dd pn="section-2.3-3.2.1.4">IP address of the NVE.</dd>
              <dt pn="section-2.3-3.2.1.5">TTL or Hop Limit:</dt>
              <dd pn="section-2.3-3.2.1.6">
                <bcp14>MUST</bcp14> be set to 255 per <xref target="RFC5082" format="default" sectionFormat="of" derivedContent="RFC5082"/>.  The receiver of an active OAM Geneve
  packet with IP/UDP encapsulation <bcp14>MUST</bcp14> drop packets whose
  TTL/Hop Limit is not 255.</dd>
            </dl>
          </dd>
        </dl>
      </section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-3-1">This document has no IANA actions.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-4-1">
   As part of a Geneve network, active OAM inherits the security considerations discussed in
   <xref target="RFC8926" format="default" sectionFormat="of" derivedContent="RFC8926"/>. Additionally, a system <bcp14>MUST</bcp14> provide control to limit
   the rate of Geneve OAM packets punted to the Geneve control plane for processing
   in order to avoid overloading that control plane.
      </t>
      <t indent="0" pn="section-4-2">
      OAM in Geneve packets uses the General TTL Security Mechanism <xref target="RFC5082" format="default" sectionFormat="of" derivedContent="RFC5082"/>,
      and any packet received with an inner TTL / Hop Count other than 255 <bcp14>MUST</bcp14> be discarded.
      </t>
    </section>
  </middle>
  <back>
    <references pn="section-5">
      <name slugifiedName="name-references">References</name>
      <references pn="section-5.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8926" target="https://www.rfc-editor.org/info/rfc8926" quoteTitle="true" derivedAnchor="RFC8926">
          <front>
            <title>Geneve: Generic Network Virtualization Encapsulation</title>
            <author fullname="J. Gross" initials="J." role="editor" surname="Gross"/>
            <author fullname="I. Ganga" initials="I." role="editor" surname="Ganga"/>
            <author fullname="T. Sridhar" initials="T." role="editor" surname="Sridhar"/>
            <date month="November" year="2020"/>
            <abstract>
              <t indent="0">Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8926"/>
          <seriesInfo name="DOI" value="10.17487/RFC8926"/>
        </reference>
        <reference anchor="RFC9780" target="https://www.rfc-editor.org/info/rfc9780" quoteTitle="true" derivedAnchor="RFC9780">
          <front>
            <title>Bidirectional Forwarding Detection (BFD) for Multipoint Networks over Point-to-Multipoint MPLS Label Switched Paths (LSPs)</title>
            <author fullname="Greg Mirsky" initials="G." surname="Mirsky">
    </author>
            <author fullname="Gyan Mishra" initials="G." surname="Mishra">
    </author>
            <author fullname="Donald E. Eastlake 3rd" initials="D." surname="Eastlake 3rd">
    </author>
            <date month="May" year="2025"/>
          </front>
          <seriesInfo name="RFC" value="9780"/>
          <seriesInfo name="DOI" value="10.17487/RFC9780"/>
        </reference>
      </references>
      <references pn="section-5.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC0792" target="https://www.rfc-editor.org/info/rfc792" quoteTitle="true" derivedAnchor="RFC0792">
          <front>
            <title>Internet Control Message Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="792"/>
          <seriesInfo name="DOI" value="10.17487/RFC0792"/>
        </reference>
        <reference anchor="RFC4443" target="https://www.rfc-editor.org/info/rfc4443" quoteTitle="true" derivedAnchor="RFC4443">
          <front>
            <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="M. Gupta" initials="M." role="editor" surname="Gupta"/>
            <date month="March" year="2006"/>
            <abstract>
              <t indent="0">This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="89"/>
          <seriesInfo name="RFC" value="4443"/>
          <seriesInfo name="DOI" value="10.17487/RFC4443"/>
        </reference>
        <reference anchor="RFC4884" target="https://www.rfc-editor.org/info/rfc4884" quoteTitle="true" derivedAnchor="RFC4884">
          <front>
            <title>Extended ICMP to Support Multi-Part Messages</title>
            <author fullname="R. Bonica" initials="R." surname="Bonica"/>
            <author fullname="D. Gan" initials="D." surname="Gan"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
            <date month="April" year="2007"/>
            <abstract>
              <t indent="0">This document redefines selected ICMP messages to support multi-part operation. A multi-part ICMP message carries all of the information that ICMP messages carried previously, as well as additional information that applications may require.</t>
              <t indent="0">Multi-part messages are supported by an ICMP extension structure. The extension structure is situated at the end of the ICMP message. It includes an extension header followed by one or more extension objects. Each extension object contains an object header and object payload. All object headers share a common format.</t>
              <t indent="0">This document further redefines the above mentioned ICMP messages by specifying a length attribute. All of the currently defined ICMP messages to which an extension structure can be appended include an "original datagram" field. The "original datagram" field contains the initial octets of the datagram that elicited the ICMP error message. Although the original datagram field is of variable length, the ICMP message does not include a field that specifies its length. Therefore, in order to facilitate message parsing, this document allocates eight previously reserved bits to reflect the length of the "original datagram" field.</t>
              <t indent="0">The proposed modifications change the requirements for ICMP compliance. The impact of these changes on compliant implementations is discussed, and new requirements for future implementations are presented.</t>
              <t indent="0">This memo updates RFC 792 and RFC 4443. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4884"/>
          <seriesInfo name="DOI" value="10.17487/RFC4884"/>
        </reference>
        <reference anchor="RFC5082" target="https://www.rfc-editor.org/info/rfc5082" quoteTitle="true" derivedAnchor="RFC5082">
          <front>
            <title>The Generalized TTL Security Mechanism (GTSM)</title>
            <author fullname="V. Gill" initials="V." surname="Gill"/>
            <author fullname="J. Heasley" initials="J." surname="Heasley"/>
            <author fullname="D. Meyer" initials="D." surname="Meyer"/>
            <author fullname="P. Savola" initials="P." role="editor" surname="Savola"/>
            <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
            <date month="October" year="2007"/>
            <abstract>
              <t indent="0">The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5082"/>
          <seriesInfo name="DOI" value="10.17487/RFC5082"/>
        </reference>
        <reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5880" quoteTitle="true" derivedAnchor="RFC5880">
          <front>
            <title>Bidirectional Forwarding Detection (BFD)</title>
            <author fullname="D. Katz" initials="D." surname="Katz"/>
            <author fullname="D. Ward" initials="D." surname="Ward"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5880"/>
          <seriesInfo name="DOI" value="10.17487/RFC5880"/>
        </reference>
        <reference anchor="RFC7365" target="https://www.rfc-editor.org/info/rfc7365" quoteTitle="true" derivedAnchor="RFC7365">
          <front>
            <title>Framework for Data Center (DC) Network Virtualization</title>
            <author fullname="M. Lasserre" initials="M." surname="Lasserre"/>
            <author fullname="F. Balus" initials="F." surname="Balus"/>
            <author fullname="T. Morin" initials="T." surname="Morin"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="October" year="2014"/>
            <abstract>
              <t indent="0">This document provides a framework for Data Center (DC) Network Virtualization over Layer 3 (NVO3) and defines a reference model along with logical components required to design a solution.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7365"/>
          <seriesInfo name="DOI" value="10.17487/RFC7365"/>
        </reference>
        <reference anchor="RFC7799" target="https://www.rfc-editor.org/info/rfc7799" quoteTitle="true" derivedAnchor="RFC7799">
          <front>
            <title>Active and Passive Metrics and Methods (with Hybrid Types In-Between)</title>
            <author fullname="A. Morton" initials="A." surname="Morton"/>
            <date month="May" year="2016"/>
            <abstract>
              <t indent="0">This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7799"/>
          <seriesInfo name="DOI" value="10.17487/RFC7799"/>
        </reference>
        <reference anchor="RFC8014" target="https://www.rfc-editor.org/info/rfc8014" quoteTitle="true" derivedAnchor="RFC8014">
          <front>
            <title>An Architecture for Data-Center Network Virtualization over Layer 3 (NVO3)</title>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <author fullname="J. Hudson" initials="J." surname="Hudson"/>
            <author fullname="L. Kreeger" initials="L." surname="Kreeger"/>
            <author fullname="M. Lasserre" initials="M." surname="Lasserre"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="December" year="2016"/>
            <abstract>
              <t indent="0">This document presents a high-level overview architecture for building data-center Network Virtualization over Layer 3 (NVO3) networks. The architecture is given at a high level, showing the major components of an overall system. An important goal is to divide the space into individual smaller components that can be implemented independently with clear inter-component interfaces and interactions. It should be possible to build and implement individual components in isolation and have them interoperate with other independently implemented components. That way, implementers have flexibility in implementing individual components and can optimize and innovate within their respective components without requiring changes to other components.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8014"/>
          <seriesInfo name="DOI" value="10.17487/RFC8014"/>
        </reference>
        <reference anchor="RFC8029" target="https://www.rfc-editor.org/info/rfc8029" quoteTitle="true" derivedAnchor="RFC8029">
          <front>
            <title>Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures</title>
            <author fullname="K. Kompella" initials="K." surname="Kompella"/>
            <author fullname="G. Swallow" initials="G." surname="Swallow"/>
            <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/>
            <author fullname="N. Kumar" initials="N." surname="Kumar"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <author fullname="M. Chen" initials="M." surname="Chen"/>
            <date month="March" year="2017"/>
            <abstract>
              <t indent="0">This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults.</t>
              <t indent="0">This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8029"/>
          <seriesInfo name="DOI" value="10.17487/RFC8029"/>
        </reference>
        <reference anchor="RFC8762" target="https://www.rfc-editor.org/info/rfc8762" quoteTitle="true" derivedAnchor="RFC8762">
          <front>
            <title>Simple Two-Way Active Measurement Protocol</title>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="G. Jun" initials="G." surname="Jun"/>
            <author fullname="H. Nydell" initials="H." surname="Nydell"/>
            <author fullname="R. Foote" initials="R." surname="Foote"/>
            <date month="March" year="2020"/>
            <abstract>
              <t indent="0">This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8762"/>
          <seriesInfo name="DOI" value="10.17487/RFC8762"/>
        </reference>
        <reference anchor="RFC9521" target="https://www.rfc-editor.org/info/rfc9521" quoteTitle="true" derivedAnchor="RFC9521">
          <front>
            <title>Bidirectional Forwarding Detection (BFD) for Generic Network Virtualization Encapsulation (Geneve)</title>
            <author fullname="X. Min" initials="X." surname="Min"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="S. Pallagatti" initials="S." surname="Pallagatti"/>
            <author fullname="J. Tantsura" initials="J." surname="Tantsura"/>
            <author fullname="S. Aldrin" initials="S." surname="Aldrin"/>
            <date month="January" year="2024"/>
            <abstract>
              <t indent="0">This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in point-to-point Generic Network Virtualization Encapsulation (Geneve) unicast tunnels used to make up an overlay network.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9521"/>
          <seriesInfo name="DOI" value="10.17487/RFC9521"/>
        </reference>
      </references>
    </references>
    <section anchor="ack" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">
  The authors express their appreciation to <contact fullname="Donald E. Eastlake 3rd"/> for his suggestions that improved the readability of the document.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <email>gregimirsky@gmail.com</email>
        </address>
      </author>
      <author initials="S." surname="Boutros" fullname="Sami Boutros">
        <organization showOnFrontPage="true">Ciena</organization>
        <address>
          <email>sboutros@ciena.com</email>
        </address>
      </author>
      <author initials="D." surname="Black" fullname="David Black">
        <organization showOnFrontPage="true">Dell</organization>
        <address>
          <email>david.black@dell.com</email>
        </address>
      </author>
      <author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti">
        <organization showOnFrontPage="true">VMware</organization>
        <address>
          <email>santosh.pallagatti@gmail.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
