< draft-xiao-nvo3-pm-geneve-00.txt		draft-xiao-nvo3-pm-geneve-01.txt >
	NVO3 Working Group X. Min		NVO3 Working Group X. Min
	Internet-Draft G. Mirsky		Internet-Draft G. Mirsky
	Intended status: Standards Track ZTE Corp.		Intended status: Standards Track ZTE Corp.
	Expires: May 5, 2020 S. Pallagatti		Expires: November 22, 2020 S. Pallagatti
	VMware		VMware
	November 2, 2019		May 21, 2020
	Performance Measurement for Geneve		Performance Measurement for Geneve
	draft-xiao-nvo3-pm-geneve-00		draft-xiao-nvo3-pm-geneve-01
	Abstract		Abstract
	This document describes the method to achieve Performance Measurement		This document describes the method to achieve Performance Measurement
	(PM) in point-to-point Generic Network Virtualization Encapsulation		(PM) in point-to-point Generic Network Virtualization Encapsulation
	(Geneve) tunnels that form an overlay network.		(Geneve) tunnels used to make up an overlay network.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 5, 2020.		This Internet-Draft will expire on November 22, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Conventions Used in This Document . . . . . . . . . . . . . . 2		2. Conventions Used in This Document . . . . . . . . . . . . . . 2
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2		2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
	3. PM Packet Transmission over Geneve Tunnel . . . . . . . . . . 3		3. PM Packet Transmission over Geneve Tunnel . . . . . . . . . . 3
	3.1. PM Encapsulation With Inner Ethernet/IP/UDP Headers . . . 3		3.1. PM Encapsulation With Inner Ethernet/IP/UDP Header . . . 3
	3.2. PM Encapsulation With Inner IP/UDP Headers . . . . . . . 5		3.2. PM Encapsulation With Inner IP/UDP Headers . . . . . . . 5
	3.3. PM Encapsulation With Inner MPLS Header . . . . . . . . . 7		4. Reception of PM packet from Geneve Tunnel . . . . . . . . . . 7
	4. Reception of PM packet from Geneve Tunnel . . . . . . . . . . 9		4.1. Demultiplexing of the PM packet . . . . . . . . . . . . . 7
	4.1. Demultiplexing of the PM packet . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10		8. Normative References . . . . . . . . . . . . . . . . . . . . 8
	8. Normative References . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	"Generic Network Virtualization Encapsulation" (Geneve)		"Generic Network Virtualization Encapsulation" (Geneve)
	[I-D.ietf-nvo3-geneve] provides an encapsulation scheme that allows		[I-D.ietf-nvo3-geneve] provides an encapsulation scheme that allows
	building an overlay network by decoupling the address space of the		building an overlay network by decoupling the address space of the
	attached virtual hosts from that of the network.		attached virtual hosts from that of the network.
	This document describes the use of Packet Loss and Delay Measurement		This document describes the use of Simple Two-way Active Measurement
	for MPLS Networks [RFC6374], as well as Simple Two-way Active		Protocol [RFC8762] to enable measuring the performance of the path
	Measurement Protocol [I-D.ietf-ippm-stamp], to enable measuring the		between two Geneve tunnel endpoints.
	performance of the path between two Geneve tunnel endpoints.
	In this document, NVE (Network Virtualization Edge) represents a		Analogous to [I-D.xiao-nvo3-bfd-geneve], in this document, NVE
	Geneve tunnel endpoint, TS (Tenant System) represents a physical or		(Network Virtualization Edge) represents the Geneve tunnel endpoint,
	virtual device attached to a Geneve tunnel endpoint, and VAP (Virtual		TS (Tenant System) represents the physical or virtual device attached
	Access Point) represents the NVE side of the interface between the		to a Geneve tunnel endpoint from the outside, and VAP (Virtual Access
	NVE and the TS.		Point) represents the NVE side of the interface between the NVE and
			the TS.
	2. Conventions Used in This Document		2. Conventions Used in This Document
	2.1. Terminology		2.1. Terminology
	GAL: Generic Associated Channel Label
	G-ACh: Generic Associated Channel
	Geneve: Generic Network Virtualization Encapsulation		Geneve: Generic Network Virtualization Encapsulation
	MPLS: Multiprotocol Label Switching
	NVE: Network Virtualization Edge		NVE: Network Virtualization Edge
	PM: Performance Measurement		PM: Performance Measurement
	STAMP: Simple Two-way Active Measurement Protocol		STAMP: Simple Two-way Active Measurement Protocol
	TS: Tenant System		TS: Tenant System
	VAP: Virtual Access Point		VAP: Virtual Access Point
	VNI: Virtual Network Identifier		VNI: Virtual Network Identifier
	2.2. Requirements Language		2.2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. PM Packet Transmission over Geneve Tunnel		3. PM Packet Transmission over Geneve Tunnel
	Analogous to what's specified in Section 3 of		PM session is originated and terminated at VAP of an NVE, selection
	[I-D.xiao-nvo3-bfd-geneve], this document considers three options of		of the PM packet encapsulation is based on how the VAP encapsulates
	PM packet encapsulation in Geneve:		the data packets. This document defines two formats of PM packet
			encapsulation in Geneve:
	o with Ethernet and IP/UDP encapsulation;		o with Ethernet and IP/UDP encapsulation;
	o with IP/UDP encapsulation;		o with IP/UDP encapsulation.
	o with MPLS encapsulation.
	3.1. PM Encapsulation With Inner Ethernet/IP/UDP Headers		3.1. PM Encapsulation With Inner Ethernet/IP/UDP Header
	If the Protocol Type field (as defined in Section 3.4 of		If the VAP that originates the PM packets is used to encapsulate
	[I-D.ietf-nvo3-geneve]) of data packets indicates that an inner		Ethernet data frames, then PM packets are encapsulated in Geneve as
	Ethernet header immediately follows the Geneve header, i.e., the		described below.
	Protocol Type equals to 0x6558 (Ethernet frame), then PM packets are
	encapsulated in Geneve as described below.
	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 Ethernet Header ~		~ Outer Ethernet Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Outer IPvX Header ~		~ Outer IPvX Header ~
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Inner UDP Header ~		~ Inner UDP Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ STAMP Test Packet ~		~ STAMP Test Packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FCS |		| Outer Ethernet FCS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Geneve Encapsulation of PM Message With the Inner		Figure 1: Geneve Encapsulation of PM Packet With the Inner
	Ethernet/IP/UDP Header		Ethernet/IP/UDP Header
	The STAMP test packet MUST be carried inside the inner Ethernet frame		The STAMP test packet MUST be carried inside the inner Ethernet frame
	of the Geneve packet, immediately after the inner IP/UDP headers.		of the Geneve packet, immediately after the inner IP/UDP headers.
	The inner Ethernet frame carrying the STAMP Test Packet has the		The inner Ethernet frame carrying the STAMP Test Packet has the
	following format:		following format:
	The Ethernet header and IP header are encoded as specified in		The Ethernet header and IP header are encoded as defined in
	Section 4 of [I-D.ietf-bfd-vxlan].		Section 3.1 of [I-D.xiao-nvo3-bfd-geneve].
	The destination UDP port MUST be set the well-known port 862 as		The destination UDP port MUST be set the well-known port 862 as
	defined in [I-D.ietf-ippm-stamp].		defined in [RFC8762].
	The STAMP Test Packet SHOULD be unauthenticated STAMP Session-Sender		The STAMP Test Packet SHOULD be unauthenticated STAMP Session-Sender
	test packet or unauthenticated STAMP Session-Reflector test packet.		test packet or unauthenticated STAMP Session-Reflector test packet.
	The STAMP Test Packet is encoded as specified in		The STAMP Test Packet is encoded as specified in [RFC8762] and
	[I-D.ietf-ippm-stamp] and [I-D.ietf-ippm-stamp-option-tlv].		[I-D.ietf-ippm-stamp-option-tlv].
	If the PM packets are encapsulated in Geneve as described above, the
	values in the Geneve header are set as follows:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Ver| Opt Len |O|C| Rsvd. | Protocol Type |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Virtual Network Identifier (VNI) | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Variable Length Options |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Geneve Header
	Opt Len field MUST be set to 0 to indicate that the header does
	not include any variable-length options.
	O bit MUST be set to 1, which indicates this packet contains a
	control message.
	C bit MUST be set to 0.
	Protocol Type field MUST be set to 0x6558 (Ethernet frame).		When the PM packets are encapsulated in Geneve in this way, the
			values in the Geneve header are set as specified in Section 3.1 of
			[I-D.xiao-nvo3-bfd-geneve].
	3.2. PM Encapsulation With Inner IP/UDP Headers		3.2. PM Encapsulation With Inner IP/UDP Headers
	If the Protocol Type field (as defined in Section 3.4 of		If the VAP that originates the PM packets is used to encapsulate IP
	[I-D.ietf-nvo3-geneve]) of data packets indicates that an inner IP		data packets, then PM packets are encapsulated in Geneve as described
	header immediately follows the Geneve header, i.e., the Protocol Type		below.
	equals to 0x0800 (IPv4) or 0x86DD (IPv6), then PM packets are
	encapsulated in Geneve as described below.
	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 Ethernet Header ~		~ Ethernet Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Outer IPvX Header ~		~ Outer IPvX Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Outer UDP Header ~		~ Outer UDP Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 6, line 39 ¶		skipping to change at page 6, line 39 ¶
	~ Inner UDP Header ~		~ Inner UDP Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ STAMP Test Packet ~		~ STAMP Test Packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FCS |		| FCS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: Geneve Encapsulation of PM Message With the Inner IP/UDP		Figure 2: Geneve Encapsulation of PM Message With the Inner IP/UDP
	Header		Header
	A STAMP test packet MUST be carried inside the inner IP/UDP packet		A STAMP test packet MUST be carried inside the inner IP packet that
	that immediately follows the Geneve header. The values in the inner		immediately follows the Geneve header. The inner IP packet carrying
	IP packet carrying the STAMP Test Packet are as follows:		the STAMP Test Packet has the following format:
	The IP header is encoded as specified in Section 3.2 of		The IP header is encoded as defined in Section 3.2 of
	[I-D.xiao-nvo3-bfd-geneve].		[I-D.xiao-nvo3-bfd-geneve].
	The destination UDP port MUST be set the well-known port 862 as		The destination UDP port MUST be set the well-known port 862 as
	defined in [I-D.ietf-ippm-stamp].		defined in [RFC8762].
	The STAMP Test Packet SHOULD be unauthenticated STAMP Session-Sender		The STAMP Test Packet SHOULD be unauthenticated STAMP Session-Sender
	test packet or unauthenticated STAMP Session-Reflector test packet.		test packet or unauthenticated STAMP Session-Reflector test packet.
	The STAMP Test Packet is encoded as specified in		The STAMP Test Packet is encoded as specified in [RFC8762] and
	[I-D.ietf-ippm-stamp] and [I-D.ietf-ippm-stamp-option-tlv].		[I-D.ietf-ippm-stamp-option-tlv].
	When the PM packets are encapsulated in Geneve in this way, the
	Geneve header follows the value set below.
	Opt Len field MUST be set to 0 to indicate there isn't any
	variable-length option.
	O bit MUST be set to 1, which indicates this packet contains a
	control message.
	C bit MUST be set to 0.
	Protocol Type field MUST be set to 0x0800 (IPv4) or 0x86DD (IPv6),
	depending on the address family of the inner IP packet.
	3.3. PM Encapsulation With Inner MPLS Header
	If the Protocol Type field (as defined in Section 3.4 of
	[I-D.ietf-nvo3-geneve]) of data packets indicates that an MPLS label
	stack immediately follows the Geneve header, i.e., the Protocol Type
	equals to 0x8847 (MPLS) or 0x8848 (MPLS with the upstream-assigned
	label), then PM packets are encapsulated in Geneve, as described
	below.
	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 Ethernet Header ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ Outer IPvX Header ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ Outer UDP Header ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |
	~ Geneve Header ~
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS Interface Context Label |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS GAL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| MPLS G-ACh |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Loss Measurement Message, |
	~ Delay Measurement Message, or ~
	| Combined Loss/Delay Measurement Message |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FCS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: Geneve Encapsulation of PM Message With the Inner MPLS GAL/
	G-ACh
	The Loss Measurement Message, Delay Measurement Message, or Combined
	Loss/Delay Measurement Message MUST be carried inside the inner MPLS
	packet that immediately follows the Geneve header. The values in the
	inner MPLS packet carrying the Loss Measurement Message, Delay
	Measurement Message, or Combined Loss/Delay Measurement Message are
	as follows:
	The MPLS Interface Context Label and the MPLS GAL (Generic
	Associated Channel Label) are encoded as specified in Section 3.3
	of [I-D.xiao-nvo3-bfd-geneve].
	The MPLS G-ACh (Generic Associated Channel) is encoded as
	specified in [RFC5586], and the "Channel Type" field of MPLS G-ACh
	MUST be set to 0x000A, 0x000C or 0x000D requested by [RFC6374],
	respectively indicating "MPLS Direct Loss Measurement", "MPLS
	Delay Measurement" or "MPLS Direct Loss and Delay Measurement".
	The Loss Measurement Message, Delay Measurement Message, and
	Combined Loss/Delay Measurement Message are encoded as specified
	in Sections 3.1 through 3.3 of [RFC6374].
	When the PM packets are encapsulated in Geneve in this way, the		When the PM packets are encapsulated in Geneve in this way, the
	Geneve header follows the value set below.		values in the Geneve header are set as specified in Section 3.2 of
			[I-D.xiao-nvo3-bfd-geneve].
	Opt Len field MUST be set to 0 to indicate there isn't any
	variable-length option.
	O bit MUST be set to 1, which indicates this packet contains a
	control message.
	C bit MUST be set to 0.
	Protocol Type field MUST be set to 0x8847 (MPLS).
	4. Reception of PM packet from Geneve Tunnel		4. Reception of PM packet from Geneve Tunnel
	Once a packet is received, NVE MUST validate the packet as described		Once a packet is received, the NVE MUST validate the packet as
	in [I-D.ietf-nvo3-geneve] and Section 4 of		specified in Section 4 of [I-D.xiao-nvo3-bfd-geneve], except that the
	[I-D.xiao-nvo3-bfd-geneve].		received STAMP test packet would be processed by STAMP Session-Sender
			or STAMP Session-Reflector, instead of BFD.
	4.1. Demultiplexing of the PM packet		4.1. Demultiplexing of the PM packet
	Similar to BFD over Geneve, multiple PM sessions may be running		Analogous to BFD over Geneve, multiple PM sessions for the same VNI
	between two NVEs, so there needs to be a mechanism for demultiplexing		may be running between two NVEs, so there needs to be a mechanism for
	received PM packets to the proper session.		demultiplexing received PM packets to the proper session.
	If the PM packet is received with Session Identifier value equals to
	0, for different PM encapsulation, the procedure for demultiplexing
	the received PM packets is different, which would follow the
	procedure for a BFD packet with Your Discriminator equals to 0, as
	specified in Section 4.1 of [I-D.xiao-nvo3-bfd-geneve].
	If the PM packet is received with a non-zero Session Identifier, then
	PM session MUST be demultiplexed only with Session Identifier as the
	key.
	With respect to PM for Geneve, the use of the specific VNI would		If the PM packet is received with STAMP Session Identifier equals to
	follow the principle as specified in Section 4.1 of		0, the procedure for demultiplexing the received PM packets would
			follow the procedure for demultiplexing the received BFD packets with
			Your Discriminator equals to 0, which is specified in Section 4.1 of
	[I-D.xiao-nvo3-bfd-geneve].		[I-D.xiao-nvo3-bfd-geneve].
			If the PM packet is received with a non-zero STAMP Session
			Identifier, then PM session MUST be demultiplexed only with STAMP
			Session Identifier as the key.
	5. Security Considerations		5. Security Considerations
	This document does not raise any additional security issues beyond		This document does not raise any additional security issues beyond
	those of the specifications referred to in the list of normative		those of the specifications referred to in the list of normative
	references.		references.
	6. IANA Considerations		6. IANA Considerations
	This document has no IANA action requested.		This document has no IANA action requested.
	7. Acknowledgements		7. Acknowledgements
	TBA.		TBA.
	8. Normative References		8. Normative References
	[I-D.ietf-bfd-vxlan]
	Networks, J., Paragiri, S., Govindan, V., Mudigonda, M.,
	and G. Mirsky, "BFD for VXLAN", draft-ietf-bfd-vxlan-07
	(work in progress), May 2019.
	[I-D.ietf-ippm-stamp]
	Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
	Two-way Active Measurement Protocol", draft-ietf-ippm-
	stamp-09 (work in progress), October 2019.
	[I-D.ietf-ippm-stamp-option-tlv]		[I-D.ietf-ippm-stamp-option-tlv]
	Mirsky, G., Xiao, M., Nydell, H., Foote, R., Masputra, A.,		Mirsky, G., Xiao, M., Nydell, H., Foote, R., Masputra, A.,
	and E. Ruffini, "Simple Two-way Active Measurement		and E. Ruffini, "Simple Two-way Active Measurement
	Protocol Optional Extensions", draft-ietf-ippm-stamp-		Protocol Optional Extensions", draft-ietf-ippm-stamp-
	option-tlv-02 (work in progress), October 2019.		option-tlv-04 (work in progress), March 2020.
	[I-D.ietf-nvo3-geneve]		[I-D.ietf-nvo3-geneve]
	Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic		Gross, J., Ganga, I., and T. Sridhar, "Geneve: Generic
	Network Virtualization Encapsulation", draft-ietf-		Network Virtualization Encapsulation", draft-ietf-
	nvo3-geneve-14 (work in progress), September 2019.		nvo3-geneve-16 (work in progress), March 2020.
	[I-D.xiao-nvo3-bfd-geneve]		[I-D.xiao-nvo3-bfd-geneve]
	Xiao, M., Mirsky, G., and J. Networks, "BFD for Geneve",		Xiao, M., Mirsky, G., and J. Networks, "BFD for Geneve",
	draft-xiao-nvo3-bfd-geneve-01 (work in progress), October		draft-xiao-nvo3-bfd-geneve-02 (work in progress), February
	2019.		2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
	"MPLS Generic Associated Channel", RFC 5586,
	DOI 10.17487/RFC5586, June 2009,
	<https://www.rfc-editor.org/info/rfc5586>.
	[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
	Measurement for MPLS Networks", RFC 6374,
	DOI 10.17487/RFC6374, September 2011,
	<https://www.rfc-editor.org/info/rfc6374>.
	[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>.
			[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple
			Two-Way Active Measurement Protocol", RFC 8762,
			DOI 10.17487/RFC8762, March 2020,
			<https://www.rfc-editor.org/info/rfc8762>.
	Authors' Addresses		Authors' Addresses
	Xiao Min		Xiao Min
	ZTE Corp.		ZTE Corp.
	Nanjing		Nanjing
	China		China
	Phone: +86 25 88013062		Phone: +86 25 88013062
	Email: xiao.min2@zte.com.cn		Email: xiao.min2@zte.com.cn
End of changes. 41 change blocks.
	219 lines changed or deleted		80 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/