Diff: rfc9772v1.txt - rfc9772.txt

	rfc9772v1.txt	rfc9772.txt

	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	[P2MP-BFD]. 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	[Note to RFC Editor: Please replace Dummy-IPv6-Prefix with
	the actual value allocated (requested in draft-ietf-mpls-p2mp-	the actual value allocated (requested in draft-ietf-mpls-p2mp-
	bfd) in IANA IPv6 Special-Purpose Address Registry.]	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

	skipping to change at line 409 ¶	skipping to change at line 408 ¶
	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>.

	5.2. Informative References	5.2. Informative References


		[P2MP-BFD] Mirsky, G., Mishra, G., and D. Eastlake, "Bidirectional
		Forwarding Detection (BFD) for Multipoint Networks over
		Point-to-Multi-Point MPLS Label Switched Path (LSP)", Work
		in Progress, Internet-Draft, draft-ietf-mpls-p2mp-bfd-11,
		19 February 2025, <https://datatracker.ietf.org/doc/html/
		draft-ietf-mpls-p2mp-bfd-11>.

	[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,
	<https://www.rfc-editor.org/info/rfc4443>.	<https://www.rfc-editor.org/info/rfc4443>.


End of changes. 5 change blocks.
	7 lines changed or deleted	13 lines changed or added
This html diff was produced by rfcdiff 1.48.