Diff: rfc9772v1.txt - rfc9772.txt

	rfc9772v1.txt	rfc9772.txt

	Internet Engineering Task Force (IETF) G. Mirsky	Internet Engineering Task Force (IETF) G. Mirsky
	Request for Comments: 9772 Ericsson	Request for Comments: 9772 Ericsson
	Category: Standards Track S. Boutros	Category: Standards Track S. Boutros
	ISSN: 2070-1721 Ciena	ISSN: 2070-1721 Ciena
	D. Black	D. Black

	Dell EMC	Dell
	S. Pallagatti	S. Pallagatti
	VMware	VMware

	April 2025	May 2025

	Active Operations, Administration, and Maintenance (OAM) for Use in	Active Operations, Administration, and Maintenance (OAM) for Use in
	Generic Network Virtualization Encapsulation (Geneve)	Generic Network Virtualization Encapsulation (Geneve)

	Abstract	Abstract

	Geneve (Generic Network Virtualization Encapsulation) is a flexible	Geneve (Generic Network Virtualization Encapsulation) is a flexible
	and extensible network virtualization overlay protocol designed to	and extensible network virtualization overlay protocol designed to
	encapsulate network packets for transport across underlying physical	encapsulate network packets for transport across underlying physical
	networks. This document specifies the requirements and provides a	networks. This document specifies the requirements and provides a

	skipping to change at line 109 ¶	skipping to change at line 109 ¶
	[RFC7799], that traverses the same set of links and interfaces and	[RFC7799], that traverses the same set of links and interfaces and
	receives the same Quality of Service treatment as the monitored	receives the same Quality of Service treatment as the monitored
	object. In this context, the monitored object refers to either	object. In this context, the monitored object refers to either
	the entire Geneve tunnel or a specific tenant flow within a given	the entire Geneve tunnel or a specific tenant flow within a given
	Geneve tunnel.	Geneve tunnel.

	Section 2.1 lists the general requirements for active OAM protocols	Section 2.1 lists the general requirements for active OAM protocols
	in the Geneve overlay network. IP encapsulation meets these	in the Geneve overlay network. IP encapsulation meets these
	requirements and is suitable for encapsulating active OAM protocols	requirements and is suitable for encapsulating active OAM protocols
	within a Geneve overlay network. Active OAM messages in a Geneve	within a Geneve overlay network. Active OAM messages in a Geneve

	overlay network are exchanged between two Geneve tunnel endpoints,	overlay network are exchanged between two Geneve tunnel endpoints;
	which may be the tenant-facing interface of the Network	each endpoint may be the tenant-facing interface of the Network
	Virtualization Edge (NVE) or another device acting as a Geneve tunnel	Virtualization Edge (NVE) or another device acting as a Geneve tunnel
	endpoint. Testing end-to-end between tenants is out of scope. For	endpoint. Testing end-to-end between tenants is out of scope. For
	simplicity, this document uses an NVE to represent the Geneve tunnel	simplicity, this document uses an NVE to represent the Geneve tunnel
	endpoint. Refer to [RFC7365] and [RFC8014] for detailed definitions	endpoint. Refer to [RFC7365] and [RFC8014] for detailed definitions
	and descriptions of an NVE.	and descriptions of an NVE.

	The IP encapsulation of Geneve OAM defined in this document applies	The IP encapsulation of Geneve OAM defined in this document applies
	to an overlay service by introducing a Management Virtual Network	to an overlay service by introducing a Management Virtual Network
	Identifier (VNI), which can be used in combination with various	Identifier (VNI), which can be used in combination with various
	values of the Protocol Type field in the Geneve header, such as	values of the Protocol Type field in the Geneve header, such as

	skipping to change at line 170 ¶	skipping to change at line 170 ¶
	perform these functions; these protocols require demultiplexing at	perform these functions; these protocols require demultiplexing at
	the receiving instance of Geneve. To improve the accuracy of the	the receiving instance of Geneve. To improve the accuracy of the
	correlation between the condition experienced by the monitored Geneve	correlation between the condition experienced by the monitored Geneve
	tunnel and the state of the OAM protocol, the OAM encapsulation is	tunnel and the state of the OAM protocol, the OAM encapsulation is
	required to comply with the following requirements:	required to comply with the following requirements:

	Requirement 1: Geneve OAM test packets MUST share the same fate as	Requirement 1: Geneve OAM test packets MUST share the same fate as
	the data traffic of the monitored Geneve tunnel.	the data traffic of the monitored Geneve tunnel.
	Specifically, the OAM test packets MUST be in-band	Specifically, the OAM test packets MUST be in-band
	with the monitored traffic and follow the same	with the monitored traffic and follow the same

	overlay and transport path as packets carrying data	overlay and transport paths as packets carrying data
	payloads in the forward direction, i.e., from the	payloads in the forward direction, i.e., from the
	ingress toward the egress endpoint(s) of the OAM	ingress toward the egress endpoint(s) of the OAM
	test.	test.

	An OAM protocol MAY be employed to monitor an entire Geneve tunnel.	An OAM protocol MAY be employed to monitor an entire Geneve tunnel.
	In this case, test packets could be in-band relative to a subset of	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	tenant flows transported over the Geneve tunnel. If the goal is to
	monitor the conditions experienced by the flow of a particular	monitor the conditions experienced by the flow of a particular
	tenant, the test packets MUST be in-band with that specific flow	tenant, the test packets MUST be in-band with that specific flow
	within the Geneve tunnel. Both scenarios are discussed in detail in	within the Geneve tunnel. Both scenarios are discussed in detail in
	Section 2.2.	Section 2.2.

	Requirement 2: The encapsulation of OAM control messages and data	Requirement 2: The encapsulation of OAM control messages and data
	packets in the underlay network MUST be	packets in the underlay network MUST be

	indistinguishable from each other from the underlay	indistinguishable.
	network IP forwarding point of view.

	Requirement 3: The presence of an OAM control message in a Geneve	Requirement 3: The presence of an OAM control message in a Geneve
	packet MUST be unambiguously identifiable to Geneve	packet MUST be unambiguously identifiable to Geneve
	functionality, such as at endpoints of Geneve	functionality, such as at endpoints of Geneve
	tunnels.	tunnels.

	Requirement 4: OAM test packets MUST NOT be forwarded to a tenant	Requirement 4: OAM test packets MUST NOT be forwarded to a tenant
	system.	system.

	A test packet generated by an active OAM protocol, whether for defect	A test packet generated by an active OAM protocol, whether for defect

	skipping to change at line 358 ¶	skipping to change at line 357 ¶
	~ Active OAM Packet ~	~ Active OAM Packet ~
	\| \|	\| \|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Figure 2: An Example of Geneve IP/UDP Encapsulation of an Active	Figure 2: An Example of Geneve IP/UDP Encapsulation of an Active
	OAM Packet	OAM Packet

	Inner IP header:	Inner IP header:
	Destination IP: The IP address MUST be set to the loopback	Destination IP: The IP address MUST be set to the loopback
	address 127.0.0.1/32 for IPv4 version. For IPv6, the address	address 127.0.0.1/32 for IPv4 version. For IPv6, the address

	MUST be selected from the Dummy IPv6 Prefix for IPv6 *Dummy-	MUST be selected from the Dummy IPv6 Prefix 100:0:0:1::/64
	IPv6-Prefix*. A source-only IPv6 dummy address is used as the	[RFC9780]. A source-only IPv6 address is used as the
	destination to generate an exception and a reply message to the	destination to generate an exception and a reply message to the
	request message received.	request message received.


	[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.]

	Source IP: IP address of the NVE.	Source IP: IP address of the NVE.

	TTL or Hop Limit: MUST be set to 255 per [RFC5082]. The receiver	TTL or Hop Limit: MUST be set to 255 per [RFC5082]. The receiver
	of an active OAM Geneve packet with IP/UDP encapsulation MUST	of an active OAM Geneve packet with IP/UDP encapsulation MUST
	drop packets whose TTL/Hop Limit is not 255.	drop packets whose TTL/Hop Limit is not 255.

	3. IANA Considerations	3. IANA Considerations

	This document has no IANA actions.	This document has no IANA actions.


	skipping to change at line 407 ¶	skipping to change at line 402 ¶

	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.	May 2017, <https://www.rfc-editor.org/info/rfc8174>.

	[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,	[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
	"Geneve: Generic Network Virtualization Encapsulation",	"Geneve: Generic Network Virtualization Encapsulation",
	RFC 8926, DOI 10.17487/RFC8926, November 2020,	RFC 8926, DOI 10.17487/RFC8926, November 2020,
	<https://www.rfc-editor.org/info/rfc8926>.	<https://www.rfc-editor.org/info/rfc8926>.


		[RFC9780] Mirsky, G., Mishra, G., and D. Eastlake 3rd,
		"Bidirectional Forwarding Detection (BFD) for Multipoint
		Networks over Point-to-Multipoint MPLS Label Switched
		Paths (LSPs)", RFC 9780, DOI 10.17487/RFC9780, May 2025,
		<https://www.rfc-editor.org/info/rfc9780>.

	5.2. Informative References	5.2. Informative References

	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,	[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
	RFC 792, DOI 10.17487/RFC0792, September 1981,	RFC 792, DOI 10.17487/RFC0792, September 1981,
	<https://www.rfc-editor.org/info/rfc792>.	<https://www.rfc-editor.org/info/rfc792>.

	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet	Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", STD 89,	Protocol Version 6 (IPv6) Specification", STD 89,
	RFC 4443, DOI 10.17487/RFC4443, March 2006,	RFC 4443, DOI 10.17487/RFC4443, March 2006,

	skipping to change at line 481 ¶	skipping to change at line 482 ¶

	Greg Mirsky	Greg Mirsky
	Ericsson	Ericsson
	Email: gregimirsky@gmail.com	Email: gregimirsky@gmail.com

	Sami Boutros	Sami Boutros
	Ciena	Ciena
	Email: sboutros@ciena.com	Email: sboutros@ciena.com

	David Black	David Black

	Dell EMC	Dell
	176 South Street
	Hopkinton, MA, 01748
	United States of America
	Email: david.black@dell.com	Email: david.black@dell.com

	Santosh Pallagatti	Santosh Pallagatti
	VMware	VMware
	Email: santosh.pallagatti@gmail.com	Email: santosh.pallagatti@gmail.com

End of changes. 9 change blocks.
	17 lines changed or deleted	15 lines changed or added
This html diff was produced by rfcdiff 1.48.