< draft-ietf-bfd-vxlan-01.txt		draft-ietf-bfd-vxlan-02.txt >
	Internet Engineering Task Force S. Pallagatti, Ed.		Internet Engineering Task Force S. Pallagatti, Ed.
	Internet-Draft Rtbrick		Internet-Draft Rtbrick
	Intended status: Standards Track S. Paragiri		Intended status: Standards Track S. Paragiri
	Expires: February 7, 2019 Juniper Networks		Expires: February 18, 2019 Juniper Networks
	V. Govindan		V. Govindan
	M. Mudigonda		M. Mudigonda
	Cisco		Cisco
	G. Mirsky		G. Mirsky
	ZTE Corp.		ZTE Corp.
	August 6, 2018		August 17, 2018
	BFD for VXLAN		BFD for VXLAN
	draft-ietf-bfd-vxlan-01		draft-ietf-bfd-vxlan-02
	Abstract		Abstract
	This document describes the use of Bidirectional Forwarding Detection		This document describes the use of the Bidirectional Forwarding
	(BFD) protocol in Virtual eXtensible Local Area Network (VXLAN)		Detection (BFD) protocol in Virtual eXtensible Local Area Network
	overlay network.		(VXLAN) overlay networks.
	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 February 7, 2019.		This Internet-Draft will expire on February 18, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	skipping to change at page 2, line 32 ¶		skipping to change at page 2, line 32 ¶
	8. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8		8. Echo BFD . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 8		10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8		11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
	13. Normative References . . . . . . . . . . . . . . . . . . . . 9		13. Normative References . . . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	"Virtual eXtensible Local Area Network (VXLAN)" has been described in		"Virtual eXtensible Local Area Network" (VXLAN) [RFC7348]. provides
	[RFC7348]. VXLAN provides an encapsulation scheme that allows		an encapsulation scheme that allows virtual machines (VMs) to
	virtual machines (VMs) to communicate in a data center network.		communicate in a data center network.
	VXLAN is typically deployed in data centers interconnecting		VXLAN is typically deployed in data centers interconnecting
	virtualized hosts, which may be spread across multiple racks. The		virtualized hosts, which may be spread across multiple racks. The
	individual racks may be part of a different Layer 3 network, or they		individual racks may be part of a different Layer 3 network, or they
	could be in a single Layer 2 network. The VXLAN segments/overlay		could be in a single Layer 2 network. The VXLAN segments/overlays
	networks are overlaid on top of these Layer 2 or Layer 3 networks.		are overlaid on top of Layer 3 network.
	A VM can communicate with another VM only if they are on the same		A VM can communicate with another VM only if they are on the same
	VXLAN. VMs are unaware of VXLAN tunnels as VXLAN tunnel is		VXLAN segment. VMs are unaware of VXLAN tunnels as a VXLAN tunnel is
	terminated on VXLAN Tunnel End Point (VTEP) (hypervisor/TOR). VTEPs		terminated on a VXLAN Tunnel End Point (VTEP) (hypervisor/TOR).
	(hypervisor/TOR) are responsible for encapsulating, and decapsulating		VTEPs (hypervisor/TOR) are responsible for encapsulating and
	frames exchanged among VMs.		decapsulating frames exchanged among VMs.
	Since underlay is an L3 network, ability to monitor path continuity,		Ability to monitor path continuity, i.e., perform proactive
	i.e., perform proactive continuity check (CC) for these tunnels is		continuity check (CC) for these tunnels, is important. The
	important. Asynchronous mode of BFD, as defined in [RFC5880], can be		asynchronous mode of BFD, as defined in [RFC5880], can be used to
	used to monitor a VXLAN tunnel. Use of [I-D.ietf-bfd-multipoint] is		monitor a VXLAN tunnel. Use of [I-D.ietf-bfd-multipoint] is for
	for future study.		future study.
	Also, BFD in VXLAN can be used to monitor the particular service		Also, BFD in VXLAN can be used to monitor the particular service
	nodes that are designated to properly handle Layer 2 broadcast,		nodes that are designated to properly handle Layer 2 broadcast,
	unknown unicast, and multicast traffic. Such nodes, often referred		unknown unicast, and multicast traffic. Such nodes, often referred
	"replicators", are usually virtual VTEPs can be monitored by physical		"replicators", are usually virtual VTEPs and can be monitored by
	VTEPs to minimize BUM traffic directed to the unavailable replicator.		physical VTEPs to minimize BUM traffic directed to the unavailable
			replicator.
	This document describes the use of Bidirectional Forwarding Detection		This document describes the use of Bidirectional Forwarding Detection
	(BFD) protocol VXLAN to enable continuity monitoring between Network		(BFD) protocol VXLAN to enable monitoring continuity of the path
	Virtualization Edges (NVEs) and/or availability of a replicator		between Network Virtualization Edges (NVEs) and/or availability of a
	service node using BFD.		replicator service node using BFD.
			In this document, the terms NVE and VTEP are used interchangeably.
	2. Conventions used in this document		2. Conventions used in this document
	2.1. Terminology		2.1. Terminology
	BFD - Bidirectional Forwarding Detection		BFD - Bidirectional Forwarding Detection
	CC - Continuity Check		CC - Continuity Check
	NVE - Network Virtualization Edge		NVE - Network Virtualization Edge
	skipping to change at page 3, line 48 ¶		skipping to change at page 3, line 51 ¶
	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. Use cases		3. Use cases
	The primary use case of BFD for VXLAN is for continuity check of a		The primary use case of BFD for VXLAN is for continuity check of a
	tunnel. By exchanging BFD control packets between VTEPs, an operator		tunnel. By exchanging BFD control packets between VTEPs, an operator
	exercises the VXLAN path in both in underlay and overlay thus		exercises the VXLAN path in both the underlay and overlay thus
	ensuring the VXLAN path availability and VTEPs reachability. BFD		ensuring the VXLAN path availability and VTEPs reachability. BFD
	failure detection can be used for maintenance. There are other use		failure detection can be used for maintenance. There are other use
	cases such as		cases such as the following:
	Layer 2 VMs:		Layer 2 VMs:
	Most deployments will have VMs with only L2 capabilities that		Most deployments will have VMs with only L2 capabilities that
	may not support L3. BFD being an L3 protocol can be used as		may not support L3. BFD being an L3 protocol can be used as a
	tunnel CC mechanism, where BFD will start and terminate at the		tunnel CC mechanism, where BFD will start and terminate at the
	NVEs, e.g., VTEPs.		NVEs, e.g., VTEPs.
	It is possible to aggregate the CC sessions for multiple		It is possible to aggregate the CC sessions for multiple
	tenants by running a BFD session between the VTEPs over VxLAN		tenants by running a BFD session between the VTEPs over VxLAN
	tunnel. In the rest of this document, terms NVE and VTEP are		tunnel.
	used interchangeably.
	Fault localization:		Fault localization:
	It is also possible that VMs are L3 aware and can host a BFD		It is also possible that VMs are L3 aware and can host a BFD
	session. In these cases, BFD sessions can be established among		session. In these cases, BFD sessions can be established among
	VMs for CC. In addition, BFD sessions can be established among		VMs for CC. Also, BFD sessions can be created among VTEPs for
	VTEPs for tunnel CC. Having a hierarchical OAM model helps		tunnel CC. Having a hierarchical OAM model helps localize
	localize faults though requires additional consideration.		faults though it requires additional consideration.
	Service node reachability:		Service node reachability:
	The service node is responsible for sending BUM traffic. In		The service node is responsible for sending BUM traffic. In
	case a service node tunnel terminates at VTEP, and it might not		case a service node tunnel terminates at a VTEP, and that VTEP
	even host VM. BFD session between TOR/hypervisor and service		might not even host VM. BFD session between TOR/hypervisor and
	node can be used to monitor service node reachability.		service node can be used to monitor service node reachability.
	4. Deployment		4. Deployment
	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 VNI number 100 and 200 respectively. Separate BFD		tunnels with VNI number 100 and 200 respectively. Separate BFD
	sessions can be established between the VTEPs (IP1 and IP2) for		sessions can be established between the VTEPs (IP1 and IP2) for
	monitoring each of the VXLAN tunnels (VNI 100 and 200). No BFD		monitoring each of the VXLAN tunnels (VNI 100 and 200). No BFD
	packets intended to Hypervisor VTEP should be forwarded to a VM as VM		packets intended for a Hypervisor VTEP should be forwarded to a VM as
	may drop BFD packets leading to a false negative. This method is		a VM may drop BFD packets leading to a false negative. This method
	applicable whether VTEP is a virtual or physical device.		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 | |
	| | | | | |		| | | | | |
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| Hypervisor VTEP (IP1) |		| Hypervisor VTEP (IP1) |
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 44 ¶
	| +---------+ +---------+ |		| +---------+ +---------+ |
	| Server 2 |		| Server 2 |
	+--------------------------+		+--------------------------+
	Figure 1: Reference VXLAN domain		Figure 1: Reference VXLAN domain
	5. BFD Packet Transmission over VXLAN Tunnel		5. BFD Packet Transmission over VXLAN Tunnel
	BFD packet MUST be encapsulated and sent to a remote VTEP as		BFD packet MUST be encapsulated and sent to a remote VTEP as
	explained in Section 5.1. Implementations SHOULD ensure that the BFD		explained in Section 5.1. Implementations SHOULD ensure that the BFD
	packets follow the same lookup path of VXLAN packets within the		packets follow the same lookup path as VXLAN data packets within the
	sender system.		sender system.
	5.1. BFD Packet Encapsulation in VXLAN		5.1. BFD Packet Encapsulation in VXLAN
	VXLAN packet format has been described in Section 5 of [RFC7348].		BFD packets are encapsulated in VXLAN as described below. The VXLAN
	The Outer IP/UDP and VXLAN headers MUST be encoded by the sender as		packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP
	defined in [RFC7348].		and VXLAN headers MUST be encoded by the sender as defined in
			[RFC7348].
	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 6, line 49 ¶		skipping to change at page 6, line 50 ¶
	~ Inner UDP Header ~		~ Inner UDP Header ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ BFD Control Message ~		~ BFD Control Message ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FCS |		| FCS |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: VXLAN Encapsulaion of BFD Control Message		Figure 2: VXLAN Encapsulation of BFD Control Message
	The BFD packet MUST be carried inside the inner MAC frame of the		The BFD packet MUST be carried inside the inner MAC frame of the
	VXLAN packet. The inner MAC frame carrying the BFD payload has the		VXLAN packet. The inner MAC frame carrying the BFD payload has the
	following format:		following format:
	Ethernet Header:		Ethernet Header:
	Destination MAC: This MUST be a dedicated MAC (TBA) Section 9		Destination MAC: This MUST be the dedicated MAC TBA (Section 9)
	or the MAC address of the destination VTEP. The details of how		or the MAC address of the destination VTEP. The details of how
	the MAC address of the destination VTEP is obtained are outside		the MAC address of the destination VTEP is obtained are outside
	the scope of this document.		the scope of this document.
	Source MAC: MAC address of the originating VTEP		Source MAC: MAC address of the originating VTEP
	IP header:		IP header:
	Source IP: IP address of the originating VTEP.		Source IP: IP address of the originating VTEP.
	skipping to change at page 7, line 45 ¶		skipping to change at page 7, line 45 ¶
	packet MUST be processed further.		packet MUST be processed further.
	The UDP destination port and the TTL of the inner Ethernet frame MUST		The UDP destination port and the TTL of the inner Ethernet frame MUST
	be validated to determine if the received packet can be processed by		be validated to determine if the received packet can be processed by
	BFD. BFD packet with inner MAC set to VTEP or dedicated MAC address		BFD. BFD packet with inner MAC set to VTEP or dedicated MAC address
	MUST NOT be forwarded to VMs.		MUST NOT be forwarded to VMs.
	To ensure BFD detects the proper configuration of VXLAN Network		To ensure BFD detects the proper configuration of VXLAN Network
	Identifier (VNI) in a remote VTEP, a lookup SHOULD be performed with		Identifier (VNI) in a remote VTEP, a lookup SHOULD be performed with
	the MAC-DA and VNI as key in the Virtual Forwarding Instance (VFI)		the MAC-DA and VNI as key in the Virtual Forwarding Instance (VFI)
	table of the originating/ terminating VTEP to exercise the VFI		table of the originating/terminating VTEP to exercise the VFI
	associated with the VNI.		associated with the VNI.
	6.1. Demultiplexing of the BFD packet		6.1. Demultiplexing of the BFD packet
	Demultiplexing of IP BFD packet has been defined in Section 3 of		Demultiplexing of IP BFD packet has been defined in Section 3 of
	[RFC5881]. Since multiple BFD sessions may be running between two		[RFC5881]. Since multiple BFD sessions may be running between two
	VTEPs, there needs to be a mechanism for demultiplexing received BFD		VTEPs, there needs to be a mechanism for demultiplexing received BFD
	packets to the proper session. The procedure for demultiplexing		packets to the proper session. The procedure for demultiplexing
	packets with Your Discriminator equal to 0 is different from		packets with Your Discriminator equal to 0 is different from
	[RFC5880]. For such packets, the BFD session MUST be identified		[RFC5880]. For such packets, the BFD session MUST be identified
	skipping to change at page 8, line 27 ¶		skipping to change at page 8, line 27 ¶
	aggregate BFD sessions between VTEP's is to establish a BFD session		aggregate BFD sessions between VTEP's is to establish a BFD session
	with VNI 0. A VTEP MAY also use VNI 0 to establish a BFD session		with VNI 0. A VTEP MAY also use VNI 0 to establish a BFD session
	with a service node.		with a service node.
	8. Echo BFD		8. Echo BFD
	Support for echo BFD is outside the scope of this document.		Support for echo BFD is outside the scope of this document.
	9. IANA Considerations		9. IANA Considerations
	IANA is requested to assign a dedicated MAC address to be used as the		IANA has assigned TBA as a dedicated MAC address to be used as the
	Destination MAC address of the inner Ethernet which carries BFD		Destination MAC address of the inner Ethernet of VXLAN when carrying
	control packet in IP/UDP encapsulation.		BFD control packets.
	10. Security Considerations		10. Security Considerations
	The document recommends setting the inner IP TTL to 1 which could		The document recommends setting the inner IP TTL to 1 which could
	lead to a DDoS attack. Thus the implementation MUST have throttling		lead to a DDoS attack. Thus the implementation MUST have throttling
	in place. Throttling MAY be relaxed for BFD packets based on port		in place. Throttling MAY be relaxed for BFD packets based on port
	number.		number.
	Other than inner IP TTL set to 1 this specification does not raise		Other than inner IP TTL set to 1 this specification does not raise
	any additional security issues beyond those of the specifications		any additional security issues beyond those of the specifications
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	Reshad Rahman		Reshad Rahman
	rrahman@cisco.com		rrahman@cisco.com
	Cisco		Cisco
	12. Acknowledgments		12. Acknowledgments
	Authors would like to thank Jeff Hass of Juniper Networks for his		Authors would like to thank Jeff Hass of Juniper Networks for his
	reviews and feedback on this material.		reviews and feedback on this material.
	Authors would also like to thank Nobo Akiya, Marc Binderberger and		Authors would also like to thank Nobo Akiya, Marc Binderberger,
	Shahram Davari for the extensive review.		Shahram Davari and Donald E. Eastlake 3rd for the extensive reviews
			and the most detailed and helpful comments.
	13. Normative References		13. Normative References
	[I-D.ietf-bfd-multipoint]		[I-D.ietf-bfd-multipoint]
	Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for		Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for
	Multipoint Networks", draft-ietf-bfd-multipoint-18 (work		Multipoint Networks", draft-ietf-bfd-multipoint-18 (work
	in progress), June 2018.		in progress), June 2018.
	[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,
End of changes. 25 change blocks.
	52 lines changed or deleted		57 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/