< draft-ietf-bfd-vxlan-12.txt		draft-ietf-bfd-vxlan-13.txt >
	BFD S. Pallagatti, Ed.		BFD S. Pallagatti, Ed.
	Internet-Draft VMware		Internet-Draft VMware
	Intended status: Standards Track S. Paragiri		Intended status: Informational S. Paragiri
	Expires: November 26, 2020 Individual Contributor		Expires: December 18, 2020 Individual Contributor
	V. Govindan		V. Govindan
	M. Mudigonda		M. Mudigonda
	Cisco		Cisco
	G. Mirsky		G. Mirsky
	ZTE Corp.		ZTE Corp.
	May 25, 2020		June 16, 2020
	BFD for VXLAN		BFD for VXLAN
	draft-ietf-bfd-vxlan-12		draft-ietf-bfd-vxlan-13
	Abstract		Abstract
	This document describes the use of the Bidirectional Forwarding		This document describes the use of the Bidirectional Forwarding
	Detection (BFD) protocol in point-to-point Virtual eXtensible Local		Detection (BFD) protocol in point-to-point Virtual eXtensible Local
	Area Network (VXLAN) tunnels used to form an overlay network.		Area Network (VXLAN) tunnels used to form 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
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 November 26, 2020.		This Internet-Draft will expire on December 18, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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 . . . . . . . . . . . . . . 3		2. Conventions Used in this Document . . . . . . . . . . . . . . 3
	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Use of the Management VNI . . . . . . . . . . . . . . . . . . 6		4. Use of the Management VNI . . . . . . . . . . . . . . . . . . 6
	5. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 6		5. BFD Packet Transmission over VXLAN Tunnel . . . . . . . . . . 6
	6. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 8		6. Reception of BFD Packet from VXLAN Tunnel . . . . . . . . . . 8
	7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 8		9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	important. The asynchronous mode of BFD, as defined in [RFC5880], is		important. The asynchronous mode of BFD, as defined in [RFC5880], is
	used to monitor a p2p VXLAN tunnel.		used to monitor a p2p VXLAN tunnel.
	In the case where a Multicast Service Node (MSN) (as described in		In the case where a Multicast Service Node (MSN) (as described in
	Section 3.3 of [RFC8293]) participates in VXLAN, the mechanisms		Section 3.3 of [RFC8293]) participates in VXLAN, the mechanisms
	described in this document apply and can, therefore, be used to test		described in this document apply and can, therefore, be used to test
	the connectivity from the source NVE to the MSN.		the connectivity from the source NVE to the MSN.
	This document describes the use of Bidirectional Forwarding Detection		This document describes the use of Bidirectional Forwarding Detection
	(BFD) protocol to enable monitoring continuity of the path between		(BFD) protocol to enable monitoring continuity of the path between
	VXLAN VTEPs, performing as Network Virtualization Endpoints, and/or		VXLAN VTEPs that are performing as Network Virtualization Endpoints,
	availability of a replicator MSN using a Management VNI (Section 4).		and/or availability of a replicator MSN using a Management VNI
	All other uses of the specification to test toward other VXLAN		(Section 4). All other uses of the specification to test toward
	endpoints are out of the scope.		other VXLAN endpoints are out of the scope.
	2. Conventions used in this document		2. Conventions Used in this Document
	2.1. Terminology		2.1. Acronyms
	BFD Bidirectional Forwarding Detection		BFD Bidirectional Forwarding Detection
	CC Continuity Check		CC Continuity Check
	p2p Point-to-point		p2p Point-to-point
	MSN Multicast Service Node		MSN Multicast Service Node
	NVE Network Virtualization Endpoint		NVE Network Virtualization Endpoint
	skipping to change at page 4, line 24 ¶		skipping to change at page 4, line 24 ¶
	Figure 1 illustrates the scenario with two servers, each of them		Figure 1 illustrates the scenario with two servers, each of them
	hosting two VMs. The servers host VTEPs that terminate two VXLAN		hosting two VMs. The servers host VTEPs that terminate two VXLAN
	tunnels with VXLAN Network Identifier (VNI) number 100 and 200		tunnels with VXLAN Network Identifier (VNI) number 100 and 200
	respectively. Separate BFD sessions can be established between the		respectively. Separate BFD sessions can be established between the
	VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100		VTEPs (IP1 and IP2) for monitoring each of the VXLAN tunnels (VNI 100
	and 200). Using a BFD session to monitor a set of VXLAN VNIs between		and 200). Using a BFD session to monitor a set of VXLAN VNIs between
	the same pair of VTEPs might help to detect and localize problems		the same pair of VTEPs might help to detect and localize problems
	caused by misconfiguration. An implementation that supports this		caused by misconfiguration. An implementation that supports this
	specification MUST be able to control the number of BFD sessions that		specification MUST be able to control the number of BFD sessions that
	can be created between the same pair of VTEPs. BFD packets intended		can be created between the same pair of VTEPs. This method is
	for a VTEP MUST NOT be forwarded to a VM, as a VM may drop BFD		applicable whether the VTEP is a virtual or physical device.
	packets, leading to a false negative. This method is applicable
	whether the VTEP is a virtual or physical device.
	+------------+-------------+		+------------+-------------+
	| Server 1 |		| Server 1 |
	| +----+----+ +----+----+ |		| +----+----+ +----+----+ |
	| |VM1-1 | |VM1-2 | |		| |VM1-1 | |VM1-2 | |
	| |VNI 100 | |VNI 200 | |		| |VNI 100 | |VNI 200 | |
	| | | | | |		| | | | | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| VTEP (IP1) |		| VTEP (IP1) |
	+--------------------------+		+--------------------------+
	skipping to change at page 7, line 40 ¶		skipping to change at page 7, line 40 ¶
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Inner UDP Header ~		~ Inner UDP Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ BFD Control Packet ~		~ BFD Control Packet ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Outer FCS |		| Outer Ethernet FCS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: VXLAN Encapsulation of BFD Control Packet		Figure 2: VXLAN Encapsulation of BFD Control Packet
	The BFD packet MUST be carried inside the inner Ethernet frame of the		The BFD packet MUST be carried inside the inner Ethernet frame of the
	VXLAN packet. The choice of Destination MAC and Destination IP		VXLAN packet. The choice of Destination MAC and Destination IP
	addresses for the inner Ethernet frame MUST ensure that the BFD		addresses for the inner Ethernet frame MUST ensure that the BFD
	Control packet is not forwarded to a tenant but is processed locally		Control packet is not forwarded to a tenant but is processed locally
	at the remote VTEP. The inner Ethernet frame carrying the BFD		at the remote VTEP. The inner Ethernet frame carrying the BFD
	Control packet- has the following format:		Control packet- has the following format:
	Ethernet Header:		Ethernet Header:
	Destination MAC: since a Management VNI is the VNI that does		Destination MAC: A Management VNI, which does not have any
	not have any tenants, the value of this field is not analyzed		tenants, will have no dedicated MAC address for decapsulated
	by the receiving VTEP.		traffic. The value X:X:X:X:X SHOULD be used in this field.
	Source MAC: MAC address associated with the originating VTEP.		Source MAC: MAC address associated with the originating VTEP.
	IP header:		IP header:
	Destination IP: IP address MUST NOT be of one of tenant's IP		Destination IP: IP address MUST NOT be of one of tenant's IP
	addresses. The IP address SHOULD be selected from the range		addresses. The IP address SHOULD be selected from the range
	127/8 for IPv4, for IPv6 - from the range ::ffff:127.0.0.0/104.		127/8 for IPv4, for IPv6 - from the range ::ffff:127.0.0.0/104.
	Alternatively, the destination IP address MAY be set to VTEP's		Alternatively, the destination IP address MAY be set to VTEP's
	IP address.		IP address.
	skipping to change at page 8, line 35 ¶		skipping to change at page 8, line 35 ¶
	encoded as specified in [RFC5881].		encoded as specified in [RFC5881].
	6. Reception of BFD Packet from VXLAN Tunnel		6. Reception of BFD Packet from VXLAN Tunnel
	Once a packet is received, the VTEP MUST validate the packet. If the		Once a packet is received, the VTEP MUST validate the packet. If the
	packet is received on the management VNI and is identified as BFD		packet is received on the management VNI and is identified as BFD
	control packet addressed to the VTEP, and then the packet can be		control packet addressed to the VTEP, and then the packet can be
	processed further. Processing of BFD control packets received on		processed further. Processing of BFD control packets received on
	non-management VNI is outside the scope of this specification.		non-management VNI is outside the scope of this specification.
	Validation of TTL / Hop Limit of the inner IP packet, as long as the		The received packet's inner IP payload is then validated according to
	related considerations for BFD control packet demultiplexing and		Sections 4 and 5 in [RFC5881].
	authentication, is performed as described in Section 5 [RFC5881].
	7. Echo BFD		7. Echo BFD
	Support for echo BFD is outside the scope of this document.		Support for echo BFD is outside the scope of this document.
	8. IANA Considerations		8. IANA Considerations
	This specification has no IANA action requested. This section may be		This specification has no IANA action requested. This section may be
	deleted before the publication.		deleted before the publication.
End of changes. 12 change blocks.
	24 lines changed or deleted		21 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/