rfc9772.original.xml   rfc9772.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
<?rfc tocdepth="3"?> docName="draft-ietf-nvo3-geneve-oam-16" number="9772" consensus="true" obsolete
<?rfc tocindent="yes"?> s="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="
<?rfc symrefs="yes"?> 3" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"
docName="draft-ietf-nvo3-geneve-oam-16" obsoletes="" updates="" submissionType=
"IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="tru
e" version="3">
<!-- xml2rfc v2v3 conversion 3.7.0 -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<front> <front>
<title>Active OAM for use in Geneve</title> <title abbrev="Active OAM for Use in Geneve">Active Operations, Administrati
<seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-geneve-oam-16"/> on, and Maintenance (OAM) for Use in Generic Network Virtualization Encapsulatio
n (Geneve)</title>
<!-- [rfced] Please note that the title of the document has been updated as
follows. Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
Style Guide").
Original:
Active OAM for use in Geneve
Current:
Active Operations, Administration, and Maintenance (OAM) for Use in
Generic Network Virtualization Encapsulation (Geneve)
-->
<seriesInfo name="RFC" value="9772"/>
<author initials="G." surname="Mirsky" fullname="Greg Mirsky"> <author initials="G." surname="Mirsky" fullname="Greg Mirsky">
<organization>Ericsson</organization> <organization>Ericsson</organization>
<address> <address>
<email>gregimirsky@gmail.com</email> <email>gregimirsky@gmail.com</email>
</address> </address>
</author> </author>
<author initials="S" surname="Boutros" fullname="Sami Boutros"> <author initials="S." surname="Boutros" fullname="Sami Boutros">
<organization>Ciena</organization> <organization>Ciena</organization>
<address> <address>
<email>sboutros@ciena.com</email> <email>sboutros@ciena.com</email>
</address> </address>
</author> </author>
<author initials="D" surname="Black" fullname="David Black"> <author initials="D." surname="Black" fullname="David Black">
<organization>Dell EMC</organization> <organization>Dell EMC</organization>
<address> <address>
<postal> <postal>
<street>176 South Street</street> <street>176 South Street</street>
<city>Hopkinton, MA</city> <city>Hopkinton, MA</city>
<code>01748</code> <code>01748</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>david.black@dell.com</email> <email>david.black@dell.com</email>
</address> </address>
</author> </author>
<author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti"> <author fullname="Santosh Pallagatti" initials="S." surname="Pallagatti">
<organization>VMware</organization> <organization>VMware</organization>
<address> <address>
<email>santosh.pallagatti@gmail.com</email> <email>santosh.pallagatti@gmail.com</email>
</address> </address>
</author> </author>
<date year="2025"/> <date year="2025" month="April"/>
<area>RTG</area>
<workgroup>nvo3</workgroup>
<area>Routing</area>
<workgroup>NVO3 Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>OAM</keyword> <keyword>OAM</keyword>
<abstract> <abstract>
<t> <t>
Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensib le network virtualization overlay protocol Geneve (Generic Network Virtualization Encapsulation) is a flexible and extensib le network virtualization overlay protocol
designed to encapsulate network packets for transport across underlying physical networks. 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. 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 G eneve overlay networks to ensure It outlines the OAM functions necessary to monitor, diagnose, and troubleshoot G eneve overlay networks to ensure
proper operation and performance. The document aims to guide the implementation of OAM mechanisms within the Geneve protocol 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 n etwork environments. to support network operators in maintaining reliable and efficient virtualized n etwork environments.
</t> </t>
</abstract> </abstract>
skipping to change at line 85 skipping to change at line 88
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
Geneve <xref target="RFC8926" format="default"/> is designed to support various scenarios of network virtualization. Geneve <xref target="RFC8926" format="default"/> is designed to support various scenarios of network virtualization.
It encapsulates multiple protocols, such as Ethernet and IPv4/IPv6, and include s metadata within the Geneve message. It encapsulates multiple protocols, such as Ethernet and IPv4/IPv6, and include s metadata within the Geneve message.
</t> </t>
<t> <t>
Operations, Administration, and Maintenance (OAM) protocols provide fault manag ement and performance monitoring functions Operations, Administration, and Maintenance (OAM) protocols provide fault manag ement and performance monitoring functions
necessary for comprehensive network operation. Active OAM protocols, as defined in <xref target="RFC7799"/>, necessary for comprehensive network operation. Active OAM protocols, as defined in <xref target="RFC7799"/>,
utilize specially constructed packets injected into the network. OAM protocols utilize specially constructed packets injected into the network. OAM protocols
such as ICMP/ICMPv6 (<xref target="RFC0792"/> and such as ICMP and ICMPv6 (<xref target="RFC0792"/> and
<xref target="RFC4443"/> respectively), Bidirectional Forwarding Detection (BF <xref target="RFC4443"/> respectively), Bidirectional Forwarding Detection (BFD
D) <xref target="RFC5880"/>, and ) <xref target="RFC5880"/>, and the
Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> are Simple Two-way Active Measurement Protocol (STAMP) <xref target="RFC8762"/> are
example of active OAM protocols. examples of active OAM protocols.
To ensure that performance metrics or detected failures To ensure that performance metrics or detected failures
are accurately related to a particular Geneve flow, it is critical that these O AM test packets share fate, i.e., are in-band, with the overlay data packets are accurately related to a particular Geneve flow, it is critical that these O AM 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: of that monitored flow when traversing the underlay network. In this document, "in-band OAM" is interpreted as follows:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
In-band OAM is an active or hybrid OAM method, as defined in <xref target="RFC7799"/>, In-band OAM is an active or hybrid OAM method, as defined in <xref target="RFC7799"/>,
that traverses the same set of links and interfaces and receives th e same Quality of Service that traverses the same set of links and interfaces and receives th e same Quality of Service
treatment as the monitored object. In this context, the monitored o bject refers to either treatment as the monitored object. In this context, the monitored o bject refers to either
the Geneve tunnel as a whole or a specific tenant flow within a giv en Geneve tunnel. the entire Geneve tunnel or a specific tenant flow within a given G eneve tunnel.
</li> </li>
</ul> </ul>
<t> <t>
<xref target="requirements"/> of this document lists the general requirements fo r active OAM protocols in the Geneve overlay network. <xref target="requirements"/> lists the general requirements for active OAM prot ocols in the Geneve overlay network.
IP encapsulation meets these requirements and is suitable for encapsulating act ive OAM protocols within a Geneve overlay network. IP encapsulation meets these requirements and is suitable for encapsulating act ive OAM protocols within a Geneve overlay network.
<!--[rfced] Please clarify; is it possible that each endpoint (rather than
the two endpoints together) is an interface of an NVE? If so, we suggest
updating this sentence as follows.
Original:
Active OAM messages in a
Geneve overlay network are exchanged between two Geneve tunnel
endpoints, which may be the tenant-facing interface of the Network
Virtualization Edge (NVE) or another device acting as a Geneve tunnel
endpoint.
Perhaps:
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.
-->
Active OAM messages in a Geneve overlay network are exchanged between two Genev e tunnel endpoints, Active OAM messages in a Geneve overlay network are exchanged between two Genev e tunnel endpoints,
which may be the tenant-facing interface which may be the tenant-facing interface
of the Network Virtualization Edge (NVE) or another device acting as a Geneve tu nnel endpoint. of the Network Virtualization Edge (NVE) or another device acting as a Geneve tu nnel endpoint.
Testing end-to-end between tenants is out of scope. Testing end-to-end between tenants is out of scope.
For simplicity, this document uses an NVE to represent the Geneve tunnel endpoi nt. For simplicity, this document uses an NVE to represent the Geneve tunnel endpoi nt.
Refer to <xref target="RFC7365"/> and <xref target="RFC8014"/> for detailed de finitions and descriptions of an NVE. Refer to <xref target="RFC7365"/> and <xref target="RFC8014"/> for detailed def initions and descriptions of an NVE.
</t> </t>
<t> <t>
The IP encapsulation of Geneve OAM defined in this document applies to an overl ay service by introducing The IP encapsulation of Geneve OAM defined in this document applies to an overl ay service by introducing
a Management Virtual Network Identifier (VNI), which can be used in combination with various values 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. 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 o utside the scope of this document. The analysis and definition of other types of OAM encapsulation in Geneve are o utside the scope of this document.
</t> </t>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conventions used in this document</name> <name>Conventions Used in This Document</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"MAY", and "OPTIONAL" in this document are to be interpreted as ",
described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="R "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
FC8174" format="default"/> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, and only when, they appear in all capitals, as shown here. "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
</t> be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Acronyms</name> <name>Acronyms</name>
<t>Geneve: Generic Network Virtualization Encapsulation </t>
<t>NVO3: Network Virtualization over Layer 3</t>
<t>OAM: Operations, Administration, and Maintenance</t>
<t>VNI: Virtual Network Identifier</t>
<t>BFD: Bidirectional Forwarding Detection</t>
<t>STAMP: Simple Two-way Active Measurement Protocol</t>
<t>NVE: Network Virtualization Edge</t>
</section> <dl spacing="normal" newline="false">
<dt>Geneve:</dt><dd>Generic Network Virtualization Encapsulation</dd
>
<dt>NVO3:</dt><dd>Network Virtualization over Layer 3</dd>
<dt>OAM:</dt><dd>Operations, Administration, and Maintenance</dd>
<dt>VNI:</dt><dd>Virtual Network Identifier</dd>
<dt>BFD:</dt><dd>Bidirectional Forwarding Detection</dd>
<dt>STAMP:</dt><dd>Simple Two-way Active Measurement Protocol</dd>
<dt>NVE:</dt><dd>Network Virtualization Edge</dd>
</dl>
</section>
</section> </section>
</section> </section>
<section anchor="active-oam-sec" numbered="true" toc="default"> <section anchor="active-oam-sec" numbered="true" toc="default">
<name>The Applicability of Active OAM Protocols in Geneve Networks</name> <name>The Applicability of Active OAM Protocols in Geneve Networks</name>
<section anchor="requirements" numbered="true" toc="default"> <section anchor="requirements" numbered="true" toc="default">
<name>Requirements for Active OAM Protocols in Geneve Networks</name> <name>Requirements for Active OAM Protocols in Geneve Networks</name>
<t> <t>
OAM protocols, whether part of fault management or performance monitoring, are i ntended to provide OAM protocols, whether part of fault management or performance monitoring, are i ntended to provide
reliable information that can be used to detect a failure, reliable information that can be used to detect a failure,
identify the defect and localize it, thus helping to identify and apply correcti ve actions to minimize the negative impact on service. identify the defect, and localize it, thus helping to identify and apply correct ive actions to minimize the negative impact on service.
Several OAM protocols are used to perform these functions; Several OAM protocols are used to perform these functions;
these protocols require demultiplexing at the receiving instance of Geneve. these protocols require demultiplexing at the receiving instance of Geneve.
To improve the accuracy of To improve the accuracy of
the correlation between the condition experienced by the monitored Geneve tunnel and the correlation between the condition experienced by the monitored Geneve tunnel and
the state of the OAM protocol the OAM encapsulation is required the state of the OAM protocol, the OAM encapsulation is required
to comply with the following requirements: to comply with the following requirements:
</t> </t>
<ul empty="true" spacing="normal"> <ol type="Requirement %d:" group="reqs">
<li> <li anchor="req-1">Geneve OAM test packets <bcp14>MUST</bcp14>
Requirement 1: Geneve OAM test packets MUST share the same fate as the data t share the same fate as the data traffic of the monitored Geneve
raffic of the monitored Geneve tunnel. tunnel.
Specifically, the OAM test packets MUST be in-band with the monitored traffic <!--[rfced] Should "follow the same overlay and transport path" be plural
and follow the same overlay and transport path as packets carrying data paylo "paths"?
ads in the forward direction,
i.e., from the ingress toward the egress endpoint(s) of the OAM test. Original:
</li> Specifically,
</ul> the OAM test packets MUST be in-band with the monitored traffic
<t> and follow the same overlay and transport path as packets carrying
An OAM protocol MAY be employed to monitor an entire Geneve tunnel. In this case data payloads in the forward direction, i.e., from the ingress
, test packets could be in-band toward the egress endpoint(s) of the OAM test.
relative to a subset of tenant flows transported over the Geneve tunnel. If the
goal is to monitor Perhaps:
the conditions experienced by the flow of a particular tenant, the test packets Specifically,
MUST be in-band with the OAM test packets MUST be in-band with the monitored traffic
that specific flow within the Geneve tunnel. Both scenarios are discussed in det and follow the same overlay and transport paths as packets carrying
ail in <xref target="control-channel-sec"/>. data payloads in the forward direction, i.e., from the ingress
</t> toward the egress endpoint(s) of the OAM test.
<ul empty="true" spacing="normal"> -->
<li> Specifically, the OAM test packets <bcp14>MUST</bcp14> be
Requirement 2: The encapsulation of OAM control messages and data packets in the in-band with the monitored traffic and follow the same overlay and
underlay network MUST be transport path as packets carrying data payloads in the forward
indistinguishable from each other from the underlay network IP forwarding point direction, i.e., from the ingress toward the egress endpoint(s) of the
of view. OAM test.
</li> </li>
<li> </ol>
Requirement 3: The presence of an OAM control message in a Geneve packet MUST be <t>An OAM protocol <bcp14>MAY</bcp14> be employed to monitor an entire
unambiguously identifiable Geneve tunnel. In this case, test packets could be in-band relative to
to Geneve functionality, such as at endpoints of Geneve tunnels. a subset of tenant flows transported over the Geneve tunnel. If the
</li> goal is to monitor the conditions experienced by the flow of a
<li> particular tenant, the test packets <bcp14>MUST</bcp14> be in-band
Requirement 4: OAM test packets MUST NOT be forwarded to a tenant system. with that specific flow within the Geneve tunnel. Both scenarios are
</li> discussed in detail in <xref target="control-channel-sec"/>.</t>
</ul>
<t> <ol type="Requirement %d:" group="reqs">
A test packet generated by an active OAM protocol, whether for defect detection <!--[rfced] How may "from the underlay network IP forwarding point
or performance measurement, of view" be rephrased for clarity?
MUST be in-band with the tunnel or data flow being monitored, as specified in Re
quirement 1. Original:
In environments where multiple paths through the domain are available, underlay Requirement 2: The encapsulation of OAM control messages and data
transport nodes packets in the underlay network MUST be indistinguishable from
can be programmed to use characteristic information to balance the load across k each other from the underlay network IP forwarding point of view.
nown paths.
It is essential that test packets follow the same route - that is, traverse the Perhaps:
same set of nodes and links Requirement 2: The encapsulation of OAM control messages and data
as a data packet of the monitored flow. Therefore, the following requirement sup packets in the underlay network MUST be indistinguishable from
ports OAM packet fate-sharing with the data flow: each other from the point of view of the forwarding in the IP
</t> underlay network.
<ul empty="true" spacing="normal">
<li> (We note the phrase "the forwarding in the IP underlay network" is used in
Requirement 5: There MUST be a way to encode entropy Section 2.2.)
information into the underlay forwarding scheme so that OAM packets -->
take the same dataflow paths as the transit traffic flows. <li anchor="req-2">The encapsulation of OAM control messages and
</li> data packets in the underlay network <bcp14>MUST</bcp14> be
</ul> indistinguishable from each other from the underlay network IP
forwarding point of view.
</li>
<li anchor="req-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">OAM test packets <bcp14>MUST NOT</bcp14> be
forwarded to a tenant system.</li>
</ol>
<t>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">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">
<li anchor="req-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>
<section anchor="control-channel-sec" numbered="true" toc="default"> <section anchor="control-channel-sec" numbered="true" toc="default">
<name>Defect Detection and Troubleshooting in Geneve Network with Active OAM</name> <name>Defect Detection and Troubleshooting in Geneve Network with Active OAM</name>
<t> <t>
This section considers two scenarios where active OAM is used to detect and loca lize defects in a Geneve network. This section considers two scenarios where active OAM is used to detect and loca lize defects in a Geneve network.
<xref target="geneve-model-fig" format="default"/> presents an example of a Gene ve domain. <xref target="geneve-model-fig" format="default"/> presents an example of a Gene ve domain.
</t> </t>
<figure anchor="geneve-model-fig"> <figure anchor="geneve-model-fig">
<name>An example of a Geneve domain</name> <name>An Example of a Geneve Domain</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
+--------+ +--------+ +--------+ +--------+
| Tenant +--+ +----| Tenant | | Tenant +--+ +----| Tenant |
| VNI 28 | | | | VNI 35 | | VNI 28 | | | | VNI 35 |
+--------+ | ................ | +--------+ +--------+ | ................ | +--------+
| +----+ . . +----+ | | +----+ . . +----+ |
| | NVE|--. .--| NVE| | | | NVE|--. .--| NVE| |
+--| A | . . | B |---+ +--| A | . . | B |---+
+----+ . . +----+ +----+ . . +----+
/ . . / . .
/ . Geneve . / . Geneve .
+--------+ / . Network . +--------+ / . Network .
| Tenant +--+ . . | Tenant +--+ . .
| VNI 35 | . . | VNI 35 | . .
+--------+ ................ +--------+ ................
| |
+----+ +----+
| NVE| | NVE|
| C | | C |
+----+ +----+
| |
| |
===================== =====================
| | | |
+--------+ +--------+ +--------+ +--------+
| Tenant | | Tenant | | Tenant | | Tenant |
| VNI 28 | | VNI 35 | | VNI 28 | | VNI 35 |
+--------+ +--------+ +--------+ +--------+
]]></artwork>
]]></artwork> </figure>
</figure>
<t> <t>
In the first case, consider when a communication problem between In the first case, consider when a communication problem between
Network Virtualization Edge (NVE) device A and NVE C exists. Network Virtualization Edge (NVE) device A and NVE C exists.
Upon the investigation, the operator discovers that the forwarding in the IP und erlay network is working accordingly. Upon investigation, the operator discovers that the forwarding in the IP underla y network is working accordingly.
Still, the Geneve connection is unstable for all NVE A and NVE C tenants. Still, the Geneve connection is unstable for all NVE A and NVE C tenants.
Detection, troubleshooting, and localization of the problem can be done regardle ss of the VNI value. Detection, troubleshooting, and localization of the problem can be done regardle ss of the VNI value.
</t> </t>
<t> <t>
In the second case, traffic on VNI 35 between NVE A and NVE B has no problems, 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. But traffic on VNI 35 between NVE A 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. and NVE C experiences problems, for example, excessive packet loss.
</t> </t>
<t> <t>
The first case can be detected and investigated using any VNI The first case can be detected and investigated using any VNI
value, whether it connects tenant systems or not; however, to value, whether it connects tenant systems or not; however, to
conform to Requirement#4 (<xref target="requirements"/>) OAM test packets SHO ULD be transmitted conform to <xref target="req-4" format="none">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 on a VNI that doesn't have any tenants. Such a Geneve tunnel is
dedicated to carrying only control and management data between the dedicated to carrying only control and management data between the
tunnel endpoints, hence it is referred to as a Geneve control tunnel endpoints, so it is referred to as a "Geneve control
channel and that VNI is referred to as the Management VNI. A channel" and that VNI is referred to as the "Management VNI". A
configured VNI MAY be used to identify the control channel, but it configured VNI <bcp14>MAY</bcp14> be used to identify the control channel, bu
is RECOMMENDED that the default value 1 be used as the Management t it
is <bcp14>RECOMMENDED</bcp14> that the default value 1 be used as the Managem
ent
VNI. Encapsulation of test packets using the Management VNI is discussed in < xref target="oam-encap-section"/>. VNI. Encapsulation of test packets using the Management VNI is discussed in < xref target="oam-encap-section"/>.
</t> </t>
<t> <t>
The control channel of a Geneve tunnel MUST NOT carry tenant data. 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 As no tenants are connected using the control channel, a system
that supports this specification MUST NOT forward a packet that supports this specification <bcp14>MUST NOT</bcp14> forward a packet
received over the control channel to any tenant. A packet received received over the control channel to any tenant. A packet received
by the system that supports this specification over the control channel MUST be forwarded if and only if it is sent by the system that supports this specification over the control channel <bcp1 4>MUST</bcp14> be forwarded if and only if it is sent
onto the control channel of the concatenated Geneve tunnel. onto the control channel of the concatenated Geneve tunnel.
Else, it MUST be terminated locally. The Else, it <bcp14>MUST</bcp14> be terminated locally. The
Management VNI SHOULD be terminated on the tenant-facing side of Management VNI <bcp14>SHOULD</bcp14> be terminated on the tenant-facing side
of
the Geneve encapsulation/decapsulation functionality, not the DC-network-faci ng the Geneve encapsulation/decapsulation functionality, not the DC-network-faci ng
side (per definitions in Section 4 of <xref target="RFC8014"/>) so that Genev e side (per definitions in <xref target="RFC8014" sectionFormat="of" section="4 "/>), so that Geneve
encap/decap functionality is included in its scope. This approach encap/decap functionality is included in its scope. This approach
causes an active OAM packet, e.g., an ICMP echo request, to be causes an active OAM packet, e.g., an ICMP echo request, to be
decapsulated in the same fashion as any other received Geneve decapsulated in the same fashion as any other received Geneve
packet. In this example, the resulting ICMP packet is handed to packet. In this example, the resulting ICMP packet is handed to
NVE's local management functionality for the processing which NVE's local management functionality for the processing which
generates an ICMP echo reply. The ICMP echo reply is encapsulated generates an ICMP echo reply. The ICMP echo reply is encapsulated
in Geneve as specified in <xref target="oam-encap-section"/>. for forwarding back to the in Geneve (as specified in <xref target="oam-encap-section"/>) for forwarding it back to the
NVE that sent the echo request. One advantage of this approach is NVE that sent the echo request. One advantage of this approach is
that a repeated ICMP echo request/reply test could detect an intermittent pro blem in that a repeated ICMP echo request/reply test could detect an intermittent pro blem in
Geneve encap/decap hardware, which would not be tested if the Geneve encap/decap hardware, which would not be tested if the
Management VNI were handled as a "special case" at the Management VNI were handled as a "special case" at the
DC-network-facing interface. DC-network-facing interface.
</t> </t>
<t> <t>
The second case is when a test packet is transmitted using The second case is when a test packet is transmitted using
the VNI value associated with the monitored service flow. By doing that, the tes t packet the VNI value associated with the monitored service flow. By doing that, the tes t packet
experiences network treatment as the tenant's packets. experiences network treatment as the tenant's packets.
skipping to change at line 320 skipping to change at line 383
</section> </section>
<section anchor="oam-encap-section" numbered="true" toc="default"> <section anchor="oam-encap-section" numbered="true" toc="default">
<name>Active OAM Encapsulation in Geneve</name> <name>Active OAM Encapsulation in Geneve</name>
<t> <t>
Active OAM over a Management VNI in the Geneve network uses an IP encapsulation. Active OAM over a Management VNI in the Geneve network uses an IP encapsulation.
Protocols such as BFD <xref target="RFC5880" format="default"/> and STAMP <xref target="RFC8762" format="default"/> use UDP transport. Protocols such as BFD <xref target="RFC5880" format="default"/> and STAMP <xref target="RFC8762" format="default"/> use UDP transport.
The destination UDP port number in the inner UDP header (<xref target="oam-genev e-encap-fig" format="default"/>) identifies the OAM protocol. The destination UDP port number in the inner UDP header (<xref target="oam-genev e-encap-fig" format="default"/>) identifies the OAM protocol.
This approach is well-known and has been used, for example, in MPLS networks <xr ef target="RFC8029" format="default"/>. This approach is well-known and has been used, for example, in MPLS networks <xr ef target="RFC8029" format="default"/>.
To use IP encapsulation for an active OAM protocol, the Protocol Type field of t he Geneve header To use IP encapsulation for an active OAM protocol, the Protocol Type field of t he Geneve header
MUST be set to the IPv4 (0x0800) or IPv6 (0x86DD) value. <xref target="RFC9521"/ > describes the use of IP encapsulation for BFD. <bcp14>MUST</bcp14> be set to 0x0800 (IPv4) or 0x86DD (IPv6). <xref target="RFC9 521"/> describes the use of IP encapsulation for BFD.
</t> </t>
<figure anchor="oam-geneve-encap-fig"> <figure anchor="oam-geneve-encap-fig">
<name>An Example of Geneve IP/UDP Encapsulation of an Active OAM Packe t</name> <name>An Example of Geneve IP/UDP Encapsulation of an Active OAM Packe t</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 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 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 IPvX Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Outer UDP Header ~ ~ Outer UDP Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Geneve Header ~ ~ Geneve Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Inner IPvX Header ~ ~ Inner IPvX Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Inner UDP Header ~ ~ Inner UDP Header ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Active OAM Packet ~ ~ Active OAM Packet ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>
Inner IP header: <!--[rfced] Regarding Section 2.3, the IANA actions for
</t> draft-ietf-mpls-p2mp-bfd are not yet complete, i.e., the
<dl newline="false" spacing="normal"> Dummy-IPv6-Prefix requested by draft-ietf-mpls-p2mp-bfd has not yet been
<dt/> assigned, so the text of this document has not been updated.
<dd>Destination IP:
The IP address MUST be set to the loop Should a reference to draft-ietf-mpls-p2mp-bfd be added?
back address 127.0.0.1/32 for IPv4 version.
For IPv6, the address MUST be selected We note that https://www.iana.org/performance/ietf-draft-status lists
from the Dummy IPv6 Prefix for IPv6 *Dummy-IPv6-Prefix*. draft-ietf-mpls-p2mp-bfd as waiting on authors since 22 Feb 2025.
A source-only IPv6 dummy address is us
ed as the destination to generate an exception and a reply message to the reques Unless the text is changed to remove this prefix, this document
t message received. will remain in AUTH48 until the Dummy-IPv6-Prefix has been assigned.
</dd>
</dl> ORIGINAL:
<t> Inner IP header:
[Note to RFC Editor: Please replace *Dummy-IPv6-Prefix* with the actual value al
located Destination IP: The IP address MUST be set to the loopback address
(requested in draft-ietf-mpls-p2mp-bfd) in IANA IPv6 Special-Purpose Address Reg 127.0.0.1/32 for IPv4 version. For IPv6, the address MUST be
istry.] selected from the Dummy IPv6 Prefix for IPv6 *Dummy-IPv6-Prefix*.
</t> A source-only IPv6 dummy address is used as the destination to
<dl newline="false" spacing="normal"> generate an exception and a reply message to the request message
<dt/> received.
<dd>Source IP: IP address of the NVE.</dd>
<dt/> [Note to RFC Editor: Please replace *Dummy-IPv6-Prefix* with the
<dd>TTL or Hop Limit: MUST be set to 255 per <xref target="RFC5082" fo actual value allocated (requested in draft-ietf-mpls-p2mp-bfd) in
rmat="default"/>. IANA IPv6 Special-Purpose Address Registry.]
The receiver of an active OAM Geneve packet with IP/UDP encapsulation -->
MUST drop packets whose TTL/Hop Limit is not 255.
</dd> <!--[rfced] Please consider whether "dummy" would be more clear
</dl> as "example" or "placeholder" or similar.
Original: the Dummy IPv6 Prefix
Original: A source-only IPv6 dummy address
-->
<dl newline="true" spacing="normal">
<dt>Inner IP header:</dt>
<dd><dl newline="false" spacing="normal">
<dt>Destination IP:</dt><dd><t>The IP address <bcp14>MUST</bcp14> be set to th
e
loopback address 127.0.0.1/32 for IPv4 version. For IPv6, the address
<bcp14>MUST</bcp14> be selected from the Dummy IPv6 Prefix for IPv6
*Dummy-IPv6-Prefix*. A source-only IPv6 dummy address is used as the
destination to generate an exception and a reply message to the request
message received.</t>
<t>[Note to RFC Editor: Please replace
*Dummy-IPv6-Prefix* with the actual value allocated (requested in
draft-ietf-mpls-p2mp-bfd) in IANA IPv6 Special-Purpose Address Registry.]</t><
/dd>
<dt>Source IP:</dt><dd>IP address of the NVE.</dd>
<dt>TTL or Hop Limit:</dt><dd><bcp14>MUST</bcp14> be set to 255 per <xref
target="RFC5082" format="default"/>. 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> </section>
<section anchor="iana-considerations" numbered="true" toc="default"> <section anchor="iana-considerations" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document has no requirements for IANA. This section can be removed before the publication.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-considerations" numbered="true" toc="default"> <section anchor="security-considerations" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
As part of a Geneve network, active OAM inherits the security considerations discussed in As part of a Geneve network, active OAM inherits the security considerations discussed in
<xref target="RFC8926" format="default"/>. Additionally, a system MUST provid e control to limit <xref target="RFC8926" format="default"/>. Additionally, a system <bcp14>MUST </bcp14> provide control to limit
the rate of Geneve OAM packets punted to the Geneve control plane for process ing the rate of Geneve OAM packets punted to the Geneve control plane for process ing
in order to avoid overloading that control plane. in order to avoid overloading that control plane.
</t> </t>
<t> <t>
OAM in Geneve packets uses the General TTL Security Mechanism <xref targe OAM in Geneve packets uses the General TTL Security Mechanism <xref target
t="RFC5082"/>, ="RFC5082"/>,
and any packet received with an inner TTL / Hop Count other than 255 MUST and any packet received with an inner TTL / Hop Count other than 255 <bcp1
be discarded. 4>MUST</bcp14> be discarded.
</t>
</section>
<section anchor="ack" numbered="true" toc="default">
<name>Acknowledgments</name>
<t>
The authors express their appreciation to Donald E. Eastlake 3rd for his sugge
stions that improved the readability of the document.
</t> </t>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
FC.2119.xml"/> 119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8174.xml"/> 174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8926.xml"/> 926.xml"/>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.7799.xml"/> 799.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.5082.xml"/> 082.xml"/>
<!-- <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/refere <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
nce.RFC.4291.xml"/> --> 792.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.0792.xml"/> 443.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
FC.4443.xml"/> 884.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
FC.4884.xml"/> 880.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.5880.xml"/> 762.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8762.xml"/> 029.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
FC.8029.xml"/> 014.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
FC.8014.xml"/> 365.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
FC.7365.xml"/> 521.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9521.xml"/>
</references> </references>
</references> </references>
<section anchor="ack" numbered="false">
<name>Acknowledgments</name>
<t>
The authors express their appreciation to <contact fullname="Donald E. Eastlak
e 3rd"/> for his suggestions that improved the readability of the document.
</t>
</section>
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice.
-->
</back> </back>
</rfc> </rfc>
 End of changes. 44 change blocks. 
258 lines changed or deleted 348 lines changed or added

This html diff was produced by rfcdiff 1.48.