draft-ietf-idr-flowspec-nvo3-06.txt		draft-ietf-idr-flowspec-nvo3-07.txt
	INTERNET-DRAFT D. Eastlake		INTERNET-DRAFT D. Eastlake
	Intended Status: Proposed Standard Futurewei Technologies		Intended Status: Proposed Standard Futurewei Technologies
	W. Hao		W. Hao
	S. Zhuang		S. Zhuang
	Z. Li		Z. Li
	Huawei Technologies		Huawei Technologies
	R. Gu		R. Gu
	China Mobil		China Mobil
	Expires: NJanuary 7, 2020 July 8, 2019		Expires: May 3, 2020 November 4, 2019
	BGP Dissemination of		BGP Dissemination of
	Network Virtualization Overlays (NVO3) Flow Specification Rules		Flow Specification Rules for Tunneled Traffic
	<draft-ietf-idr-flowspec-nvo3-06.txt>		draft-ietf-idr-flowspec-nvo3-07
	Abstract		Abstract
	This draft specifies a new subset of component types to support the		This draft specifies a Border Gateway Protocol Network Layer
	(Network Virtualization Overlays (NVO3)) flow-spec application.		Reachability Information (BGP NLRI) encoding format for flow
			specifications (RFC 5575bis) that can match on a variety of tunneled
			traffic. In addition, flow specification components are specified for
			certain tunneling header fields.
	Status of This Document		Status of This Document
	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.
	Distribution of this document is unlimited. Comments should be sent		Distribution of this document is unlimited. Comments should be sent
	to the authors or the TRILL Working Group mailing list		to the authors or the IDR Working Group mailing list <idr@ietf.org>.
	<dnsext@ietf.org>.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft		http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft
	Shadow Directories can be accessed at		Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	INTERNET-DRAFT NVO3 BGP Flow-Spec		INTERNET-DRAFT BGP Tunnel Flow-Spec
	Table of Contents		Table of Contents
	1. Introduction............................................3		1. Introduction............................................3
	1.1 Terminology............................................5		1.1 Terminology............................................3
	2. NVO3 Flow Specification Encoding........................6		2. Tunneled Traffic Flow Specification NLRI................5
	3. NVO3 Flow Specification Traffic Actions.................8		2.1 SAFI Code Point........................................6
			2.2 Component Code Points..................................6
			2.3 Specific Tunnel Types..................................8
			2.3.1 VXLAN................................................8
			2.3.2 VXLAN-GPE............................................8
			2.3.3 NVGRE................................................9
			2.3.4 L2TPv3...............................................9
			2.3.5 GRE.................................................10
			2.3.6 IP-in-IP............................................10
			2.4 Tunneled Traffic Actions..............................11
	4. Security Considerations.................................8		3. Order of Traffic Filtering Rules.......................12
	5. IANA Considerations.....................................8		4. Flow Spec Validation...................................13
	Normative References.......................................9		5. Security Considerations................................13
	Informative References.....................................9		6. IANA Considerations....................................13
	Acknowledgments...........................................11		Normative References......................................14
	Authors' Addresses........................................11		Informative References....................................15
	INTERNET-DRAFT NVO3 BGP Flow-Spec		Acknowledgments...........................................16
			Authors' Addresses........................................16
			INTERNET-DRAFT BGP Tunnel Flow-Spec
	1. Introduction		1. Introduction
	BGP Flow-spec is an extension to BGP that supports the dissemination		BGP Flow-spec [RFC5575bis] is an extension to BGP that supports the
	of traffic flow specification rules. It uses the BGP Control Plane		dissemination of traffic flow specification rules. It uses the BGP
	to simplify the distribution of Access Control Lists (ACLs) and		control plane to simplify the distribution of Access Control Lists
	allows new filter rules to be injected to all BGP peers		(ACLs) and allows new filter rules to be injected to all BGP peers
	simultaneously without changing router configuration. A typical		simultaneously without changing router configuration. A typical
	application of BGP Flow-spec is to automate the distribution of		application of BGP Flow-spec is to automate the distribution of
	traffic filter lists to routers for Distributed Denial of Service		traffic filter lists to routers for Distributed Denial of Service
	(DDOS) mitigation.		(DDOS) mitigation.
	[RFC5575bis] defines a new BGP Network Layer Reachability Information		BGP Flow-spec defines a BGP Network Layer Reachability Information
	(NLRI) format used to distribute traffic flow specification rules.		(NLRI) format used to distribute traffic flow specification rules.
	NLRI (AFI=1, SAFI=133) is for IPv4 unicast filtering. NLRI (AFI=1,		AFI=1/SAFI=133 is for IPv4 unicast filtering. AFI=1/SAFI=134 is for
	SAFI=134) is for BGP/MPLS VPN filtering. [IPv6-FlowSpec] and [Layer2-		IPv4 BGP/MPLS VPN filtering. [FlowSpecV6] and [Layer2- FlowSpec]
	FlowSpec] extend the flow-spec rules for IPv6 and layer 2 Ethernet		extend the flow-spec rules for IPv6 and layer 2 Ethernet packets
	packets respectively. All these previous flow specifications match		respectively. All these previous flow specifications match only a
	only single layer IP/Ethernet information fields like		single level of IP/Ethernet information fields such as
	source/destination MAC, source/destination IP prefix, protocol type,		source/destination IP prefix, protocol type, source/destination MAC,
	ports, and the like.		ports, EtherType and the like.
	In the cloud computing era, multi-tenancy has become a core		In the cloud computing era, multi-tenancy has become a core
	requirement for data centers. Since Network Virtualization Overlays		requirement for data centers. It is increasingly common to see
	(NVO3 [RFC8014]) can satisfy multi-tenancy key requirements, this		tunneled traffic with a field to distinguish tenants. An example is
	technology is being deployed in an increasing number of cloud data		the Network Virtualization Over Layer 3 (NVO3 [RFC8014]) overlay
	center networks. NVO3 is an overlay technology and VXLAN [RFC7348]		technology that can satisfy multi-tenancy key requirements. VXLAN
	and NVGRE [RFC7367] are two typical NVO3 encapsulations. GENEVE		[RFC7348] and NVGRE [RFC7637] are two typical NVO3 encapsulations.
	[GENEVE], GUE [GUE] and GPE [GPE] are three emerging NVO3		Other encapsulations such as IP-in-IP or GRE may be encountered.
	encapsulations. Because it is an overlay technology involving an		Because these tunnel / overlay technologies involving an additional
	additional level of encapsulation, flow specification matching on the		level of encapsulation, flow specification that can match on the
	inner header as well as the outer header, as specified below, is		inner header as well as the outer header are needed.
	needed.
	INTERNET-DRAFT NVO3 BGP Flow-Spec
	+--+
	|CE|
	+--+
	|
	+----+
	+----| PE |----+
	+---------+ | +----+ | +---------+
	+----+ | +---+ +---+ | +----+
	|NVE1|--| | | | | |--|NVE3|
	+----+ | |GW1| |GW3| | +----+
	| +---+ +---+ |
	| NVO-1 | MPLS | NVO-2 |
	| +---+ +---+ |
	| | | | | |
	+----+ | |GW2| |GW4| | +----+
	|NVE2|--| +---+ +---+ |--|NVE4|
	+----+ +---------+ | | +---------+ +----+
	+--------------+
	Figure 1. NVO3 Data Center Interconnection
	The MPLS L2/L3 VPN in the WAN network can be used for NVO3 based data
	center network interconnection. When the Data Center (DC) and the WAN
	are operated by the same administrative entity, the Service Provider
	can decide to integrate the gateway (GW) and WAN Edge PE functions in
	the same router for capital and operational cost saving reasons. This
	is illustrated in Figure 1. There are two interconnection solutions
	as follows:
	1. End-to-end NVO3 tunnel across different data centers: NVE1
	performs NVO3 encapsulation for DC interconnection with NVE3. The
	destination VTEP IP is NVE3's IP. The GW doesn't perform NVO3
	tunnel termination. The DC interconnect WAN is pure an underlay
	network.
	2. Segmented NVO3 tunnels across different data centers: NVE1 doesn't
	perform end-to-end NVO3 encapsulation to NVE3 for DC
	interconnection. The GW performs NVO3 tunnel encapsulation
	termination, and then transmits the inner original traffic through
	an MPLS network to the peer data center GW. The peer data center
	GW terminates MPLS encapsulation, and then performs NVO3
	encapsulation to transmit the traffic to the local NVE3.
	In the first solution, to differentiate bandwidth and Quality of
	Service (QoS) among different tenants or applications, different
	traffic engneered tunnels in the WAN network will be used to carry
	the end-to-end NVO3 encapsulation traffic using VN ID, NVO3 outer
	header DSCP, and other fields as the traffic classification match
	part. The BGP Flow-spec protocol can be used to set the traffic
	classification on all GWs simultaneously.
	INTERNET-DRAFT NVO3 BGP Flow-Spec
	In the second solution, a centralized BGP speaker can be deployed for
	DDOS mitigation in the WAN network. When the analyzer detects
	abnormal traffic, it will automatically generate Flow-spec rules and
	distribute them to each GW through the BGP Flow-spec protocol, the
	match part should include matching on inner or outer L2/L3 layer or
	NVO3 headers.
	In summary, the Flow specification match part on the GW/PE should be		In summary, the Flow specifications should be able to include inner
	able to include inner layer 2 Ethernet header, inner layer 3 IP		nested header information as well as fields specific to the type of
	header, outer layer 2 Ethernet header, outer layer 3 IP header,		tunneling in use such as virtual network / tenant ID. This draft
	and/or NVO3 header information. Because the current flow-spec		specifies methods for accomplishing this using SAFI=TBD1 and a new
	matching facilities lack a layer indicator and NVO3 header		NLRI encoding.
	information, those facilities can't be used directly for traffic
	filtering based on NVO3 headers or on a specified layer header
	directly. This draft specifies a new subset of component types to
	support the NVO3 flow-spec application.
	1.1 Terminology		1.1 Terminology
	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.
	The reader is assumed to be familiar with BGP and NVO3 terminology.		INTERNET-DRAFT BGP Tunnel Flow-Spec
	The following terms and acronyms are used in this document with the
			The reader is assumed to be familiar with BGP terminology. The
			following terms and acronyms are used in this document with the
	meaning indicated:		meaning indicated:
	ACL - Access Control List		ACL - Access Control List
	DC - Data Center
	DDOS - Distributed Denial of Service (Attack)		DDOS - Distributed Denial of Service (Attack)
	DSCP - Differentiated Services Code Point		DSCP - Differentiated Services Code Point
	GW - gateway		GRE - Generic Router Encapsulation [RFC2890]
			L2TPv3 - Layer Two Tunneling Protocol - Version 3 [RFC3931]
			NLRI - Network Layer Reachability Information
			NVGRE - Network Virtualization Using Generic Routing Encapsulation
			[RFC7637]
			NVO3 - Network Virtual Overlay Layer 3 [RFC8014]
	VN - virtual network		VN - virtual network
	VTEP - Virtual Tunnel End Point		VXLAN - Virtual eXtensible Local Area Network [RFC7348]
	WAN - wide area network		INTERNET-DRAFT BGP Tunnel Flow-Spec
	INTERNET-DRAFT NVO3 BGP Flow-Spec		2. Tunneled Traffic Flow Specification NLRI
	2. NVO3 Flow Specification Encoding		The Flow-spec rules in [RFC5575bis], [FlowSpecV6], and [FlowSpecL2]
			can only recognize flows based on one level of header in a data
			packet. To enable flow specification of tunneled traffic, a new SAFI
			(TBD1) and NLRI encoding are introduced. This encoding, shown in
			Figure 1, enables flow specification of more than one layer of header
			when needed.
	The current Flow-spec rules can only recognize flows based on the		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	outer layer header of NVO3 encapsulation data packets. To enable		| Length 2 bytes |
	traffic filtering based on an NVO3 header and on an inner header of		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	NVO3 packets, a new component type acting as a delimiter is		| Tunnel Type 2 bytes |
	introduced. The delimiter type is used to indicate the boundary		+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	between the inner and outer layer component types for NVO3 data		Flags:
	packets. All the component types defined in [RFC5575bis],		+--+--+--+--+--+--+--+--+
	[IPv6-FlowSpec], [Layer2-FlowSpec], and the like can be used for the		| D| I| Reserved | 1 byte
	inner or outer header as indicated by the use of delimiters.		+--+--+--+--+--+--+--+--+
			Optional Routing Discriminator:
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			| |
			+ +
			| |
			+ Routing Discriminator 8 bytes +
			| |
			+ +
			| |
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			Outer Flow-spec:
			+--+--+--+--+--+--+--+--+
			| Outer Flowspec Length : 1 or 2 bytes
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			| Outer Flowspec variable :
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			Optional Inner Flow-spec:
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			| Inner AFI 2 bytes |
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			| Inner Flowspec Length : 1 or 2 bytes
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
			| Inner Flowspec variable :
			+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
	Because the NVO3 outer layer address normally belongs to a public		Figure 1. Tunneled Traffic Flow-spec NLRI
	network, the "Flow Specification" NLRI for the outer layer header
	doesn't need to include a Route Distinguisher field (8 bytes). If the
	outer layer address belongs to a VPN, the NLRI format for the outer
	header should consist of a fixed-length Route Distinguisher field (8
	bytes) corresponding to the VPN. This Route Distinguisher is followed
	by the detail flow specifications for the outer layer.
	The VN ID is the identification for each tenant network. The "Flow		Length - The NLRI Length encoded as an unsigned integer including the
	Specification" NLRI for an NVO3 header part should always include the		Tunnel Type.
	VN ID field but a Route Distinguisher field does not need to be
	included.
	The inner layer MAC/IP address is always associated with a VN ID.		Tunnel Type - The type of tunnel using a value from the IANA BGP
	Thus the NLRI format for the inner header should consist of a fixed-		Tunnel Encapsulation Attribute Tunnel Types registry.
	length VN ID field (4 bytes). The VN ID is followed by the detailed
	flow specifications for the inner layer. The NLRI length field shall
	include both the 4 bytes of the VN ID as well as the subsequent flow
	specification. In the NVO3 terminating into a VPN scenario, if
	multiple access VN IDs map to one VPN instance, one shared VN ID can
	be carried in the Flow-Spec rule to enforce the rule on the entire
	VPN instance and the shared VN ID and VPN correspondence should be
	configured on each VPN PE beforehand. In this case, the function of
	the layer3 VN ID is the same as a Route Distinguisher: it acts as the
	identification of the VPN instance.
	This document specifies the following Flow-Spec Component Types for		INTERNET-DRAFT BGP Tunnel Flow-Spec
	use with NVO3 flows:
	Type TBD1 - Delimiter type		Flags: D bit - Indicates the presence of the Routing Discriminator
	Encoding: <type (1 octet), length (1 octet), Value>.		(see below).
	When this delimiter type is present, it indicates the component		Flags: I bit - Indicates the presence of an inner AFI and Flow-spec.
	types and layer for the NVO3 header fields immediately
	following. At the same time, it indicates the end of the
	component types belonging to the previous delimiter.
	The value field defines encapsulation type and is encoded as:		Flags: Reserved - Six bits that MUST be sent as zero and ignored on
			receipt.
	INTERNET-DRAFT NVO3 BGP Flow-Spec		Routing Discriminator - If the outer layer 3 address belongs to a
			BGP/MPLS VPN, the routing discriminator can be included to
			support traffic filtering within that VPN. Because NVO3 outer
			layer addresses normally belong to a public network, a Route
			Distinguisher field is normally not needed for NVO3.
	| 0 1 2 3 4 5 6 7 |		Outer Flowspec / Length - The flow specification for the outer
	+---+---+---+---+---+---+---+---+		header. The length is encoded as provided in Section 4.1 of
	| Encap Type |		[RFC5575bis]. The AFI for the outer flowspec is that AFI at the
	+---+---+---+---+---+---+---+---+		beginning of the BGP multiprotocol MP_REACH_NLRI or
	| I | O | Resv |		MP_UNREACH_NLRI containing the tunneled traffic flow
	+---+---+---+---+---+---+---+---+		specification NLRI.
	This document defines the following Encap types:		Inner AFI - Depending on the Tunnel Type, there may be an inner AFI
			that indicates the address family for the inner flow
			specification. There is no need for a SAFI as it is
			automatically TBD1, the SAFI for a tunneled traffic flow
			specification.
	- VXLAN: Tunnel Type = 0		Inner Flowspec / Length - Depending on the Tunnel Type, there may be
			an inner flow specification for the header level encapsulated
			within the outer header. The length is encoded as provided in
			Section 4.1 of [RFC5575bis].
	- NVGRE: Tunnel Type = 1		2.1 SAFI Code Point
	I: If I is set to one, it indicates the component types for the		Use of the tunneled traffic flow specification NLRI format is
	inner layer of NVO3 headers immediately follow.		indicated by SAFI=TBD1. This is used in conjunction with the AFI for
			the outer layer 3 header, that is AFI=1 for IPv4 and AFI=2 for IPv6.
	O: If O is set to one, it indicates the component types for the		2.2 Component Code Points
	outer layer of NVO3 headers immediately follow.
	For the NVO3 header part, the following additional two component types		For flow specification based on certain tunnel header fields, the
	are introduced.		component types below are added. These are associated with the Tunnel
			Type and MAY appear in the outer flow specification or, if it is
			present, in the inner flow specification.
	Type TBD2 - VN ID		INTERNET-DRAFT BGP Tunnel Flow-Spec
			Type TBD2 - VN ID
	Encoding: <type (1 octet), length (1 octet), [op, value]+>.		Encoding: <type (1 octet), length (1 octet), [op, value]+>.
	Defines a list of {operation, value} pairs used to match the		Defines a list of {operation, value} pairs used to match the
	24-bit VN ID that is used as the tenant identification in NVO3		24-bit VN ID that is used as the tenant identification in some
	networks. For NVGRE encapsulation, the VN ID is equivalent to		tunneling headers. For VXLAN encapsulation, the VN ID is the
	VSID. Values are encoded as 1- to 3-byte quantities.		VNI. For NVGRE encapsulation, the VN ID is the VSID. op is
			encoded as specified in Section 4.2.3 of [RFC5575bis]. Values
			are encoded as 1- to 3-byte quantities.
	Type TBD3 - Flow ID		Type TBD3 - Flow ID
			Encoding: <type (1 octet), length (1 octet), [op, value]+>
			Defines a list of {operation, value} pairs used to match 8-bit
			Flow ID fields which are currently only useful for NVGRE
			encapsulation. op is encoded as specified in Section 4.2.3 of
			[RFC5575bis]. Values are encoded as 1-byte quantity.
			Type TBD4 - Session
	Encoding: <type (1 octet), length (1 octet), [op, value]+>		Encoding: <type (1 octet), length (1 octet), [op, value]+>
	Defines a list of {operation, value} pairs used to match 8-bit		Defines a list of {operation, value} pairs used to match a
	Flow ID fields which are only useful for NVGRE encapsulation.		32-bit Session field. This field is called Key in GRE [RFC2890]
	Values are encoded as 1-byte quantity.		encapsulation and Session ID in L2TPv3 encapsulation. op is
			encoded as specified in Section 4.2.3 of [RFC5575bis]. Values
			are encoded as a 1, 2, or 4 byte quantity.
	INTERNET-DRAFT NVO3 BGP Flow-Spec		Type TBD5 - Cookie
			Encoding: <type (1 octet), length (1 octet), [op, value]+>
	3. NVO3 Flow Specification Traffic Actions		Defines a list of {operation, value} pairs used to match a
			variable length Cookie field. This is only useful in L2TPv3
			encapsulation. op is encoded as specified in Section 4.2.3 of
			[RFC5575bis]. Values are encoded as a 1, 2, 4, or 8 byte
			quantity. If the Cookie does not fit exactly into the value
			length, it is left justified, that is, padded with following
			bytes the MUST be sent as zero and ignored on receipt.
	The current traffic filtering actions are used for NVO3 encapsulation		Type TBD6 - VXLAN-GPE Flags
	traffic. For Traffic Marking, only the DSCP in the outer header can		Encoding: <type (1 octet), length (1 octet), [op, bitmask]+>
	be modified.
	4. Security Considerations		Defines a list of {operation, value} pairs used to match
			against the VSLAN-GPE flags field. op is encoded as in Section
			4.2.9 of [RFC5575bis]. bitmask is encoded as 1 byte.
			INTERNET-DRAFT BGP Tunnel Flow-Spec
			2.3 Specific Tunnel Types
			The following subsections describe how to handle flow specification
			for several specific tunnel types.
			2.3.1 VXLAN
			The headers on a VXLAN [RFC7348] data packet are an outer Ethernet
			header, an outer IP header, a UDP header, the VXLAN header, and an
			inner Ethernet header. This inner Ethernet header is frequently, but
			not always, followed by an inner IP header. If the tunnel type is
			VXLAN, the I flag MUST be set.
			The version (IPv4 or IPv6) of the outer IP header is indicated by the
			AFI at the beginning of the multiprotocol MP_REACH_NLRI or
			MP_UNREACH_NLRI containing the tunneled traffic flow specification
			NLRI. The outer flowspec is used to filter the outer headers and the
			UDP header.
			The inner flowspec is used on the Inner Ethernet header [FlowSpecL2].
			If the inner AFI is 25, then whether or not an IP header follows the
			inner Ethernet header is ignored and the inner flowspec SHOULD NOT
			contain and IPv4 or IPv6 flowspec components. If the inner AFI is 1
			or 2, to match the flowspec the Inner Ethernet header must be
			followed by an IPv4 or IPv6 header, respectively, and the inner
			flowspec is also used to filter that inner IP header.
			A component filtering on the VXLAN header VN ID (VNI) can appear in
			either the outer or inner flowspec. The inner MAC/IP address is
			associated with a VN ID. In the NVO3 terminating into a VPN scenario,
			if multiple access VN IDs map to one VPN instance, one shared VN ID
			can be carried in the Flow-Spec rule to enforce the rule on the
			entire VPN instance and the shared VN ID and VPN correspondence
			should be configured on each VPN PE beforehand. In this case, the
			function of the layer 3 VN ID is the same as a Route Discriminator:
			it acts as the identification of the VPN instance.
			2.3.2 VXLAN-GPE
			VXLAN-GPE [GPE] is similar to VXLAN and the VXLAN-GPE header is the
			same size as the VXLAN header but has been extended from the VXLAN
			header by specifying a number of bits that are reserved in the VXLAN
			header. In particular, a number of additional flag bits are specified
			and a Next Protocol field is added that is valid if the P flag bit is
			set. These flags bits can be tested using the VXLAN-GPE Flags
			component defined above. VXLAN and VXLAN-GPE are distinguished by the
			INTERNET-DRAFT BGP Tunnel Flow-Spec
			port number in the UDP header the precedes the VXLAN or VXLAN-GPE
			headers.
			If the VXLAN-GPE header P flag is zero, then the header is followed
			by the same sequence as for VXLAN and the same flow-spec choices
			apply (see Section 2.3.1).
			If the VXLAN-GPE header P flag is one and that header's next protocol
			field is 1, then the VXLAN-GPE header is followed by an IPv4 header.
			The inner AFI/flowspec match only if the inner AFI is 1 and the inner
			flowspec matches.
			If the VXLAN-GPE header P flag is one and that header's next protocol
			field is 2, then the VXLAN-GPE header is followed by an IPv6 header.
			The inner AFI/flowspec match only if the inner AFI is 2 and the inner
			flowspec matches.
			2.3.3 NVGRE
			NVGRE [RFC7637] is very similar to VXLAN except that the UDP header
			and VXLAN header immediately after the outer IP header are replaced
			by a GRE (Generic Router Encapsulation) header. The GRE header as
			used in NVGRE has no Checksum or Reserved1 field as shown in
			[RFC2890] but there are Virtual Subnet ID and FlowID fields in place
			of what is labeled in [RFC2890] as the Key field. Processing and
			restrictions for NVGRE are as in Section 2.3.1 eliminating references
			to a UDP header and replacing references to the VXLAN header and its
			VN ID with references to the GRE header and its VN ID (VSID) and Flow
			ID.
			2.3.4 L2TPv3
			The headers on an L2TPv3 [RFC3931] packets are an outer Ethernet
			header, an outer IP header, the L2TPv3 header, an inner Ethernet
			header, and possibly an inner IP header if indicated by the inner
			Ethernet header EtherType. The outer flowspec operates on the outer
			headers that precede the GRE header. The version of IP is specified
			by the outer AFI at the beginning of the MP_REACH_NLRI or
			MP_UNREACH_NLRI.
			The L2TPv3 header consists of a 32-bit Session ID followed by a
			variable length Cookie (maximum length 8 bytes). The Session ID and
			Cookie can be filtered for by using the Session and Cookie flowspec
			components. To filter on Cookie or even be able to bypass Cookie and
			parse the remainder of the L2TPv3 packet, the node implementing
			flowspec needs to know the length and/or value of the Cookie fields
			INTERNET-DRAFT BGP Tunnel Flow-Spec
			of interest. This is negotiated at L2TPv3 session establishment and
			it is out of scope for this document how the node would learn this
			information. Of course, if flowspec is being used for DDOS mitigation
			and the Cookie has a fixed length and/or value in the DDOS traffic,
			this could be learned by inspecting that traffic.
			If the I flag bit is zero, then no filtering is done on data beyond
			the L2TPv3 header. If the I flag is one, indicating the presence of
			an inner flowspec, and the node implementing flowspec does not know
			the length of the L2TPv3 header Cookie, the match fails. If that node
			does know the length of that Cookie, the inner flowspec if matched
			against the headers at the beginning of that data using the inner
			AFI. If the inner AFI is 1 or 2, then an inner IP header is required
			and filtering can be done on the Ethernet header immediately after
			the L2TPv3 header and the following IPv4 or IPv6 headers
			respectively. If the inner AFI is 25, filtering SHOULD only be done
			on the inner Ethernet header [FlowSpecL2].
			2.3.5 GRE
			Generic Router Encapsulation (GRE [RFC2890]) is a common type of
			encapsulation. The outer flowspec operates on the outer headers that
			precede the GRE header. The version of IP is specified by the outer
			AFI at the beginning of the MP_REACH_NLRI or MP_UNREACH_NLRI.
			If the I flag bit is zero, no filtering is done on data after the GRE
			header. If the I flag bit is one, then there is an inner AFI and
			flowspec and the Protocol Type field of the GRE header must match the
			inner AFI as follows for the flowspec to match:
			GRE Protocol Type Inner AFI
			------------------- -----------
			0x0800 (IPv4) 1
			0x86DD (IPv6) 2
			0x6558 25
			With the I flag a one and the inner AFI and GRE Protocol Type fields
			match, the inner flowspec is used to filter the inner Ethernet header
			(AFI=25) or the inner IP and Ethernet headers (AFI=1 or 2).
			2.3.6 IP-in-IP
			IP-in-IP encapsulation is shown when the outer IP header indicates an
			inner IP IPv4 or IPv6 header by the value of the outer IP header's
			Protocol (IPv4) or Next Protocol (IPv6) field. If the Tunnel Type is
			IP-in-IP, the I flag MUST be set.
			INTERNET-DRAFT BGP Tunnel Flow-Spec
			The version of the outer IP header (IPv4 or IPv6) matched is
			indicated by the AFI at the beginning of the MP_REACH_NLRI or
			MP_UNREACH_NLRI. The version of the inner IP header is indicated by
			the inner AFI. The outer flowspec applies to the outer IP header and
			the inner flowspec applies to the inner IP header.
			2.4 Tunneled Traffic Actions
			The previously specified traffic filtering actions are used for
			tunneled traffic [RFC5575bis] [FlowSpecL2]. For Traffic Marking in
			NVO3, only the DSCP in the outer header can be modified.
			INTERNET-DRAFT BGP Tunnel Flow-Spec
			3. Order of Traffic Filtering Rules
			In comparing an applicable tunneled traffic flow specification with a
			non-tunneled flow specification, the tunneled specification has
			precedence.
			If comparing two tunneled traffic flow specifications, if both are
			applicable, the tunnel types will be the same. If only one has a
			Routing Discriminator, it has precedence. If both have a Routing
			Discriminator, those discriminators are compared as unsigned integers
			and the one with the smaller magnitude Routing Discriminator has
			precedence.
			If neither has a Routing Discriminator or they have equal Routing
			Discriminators, the order of precedence is determined by comparing
			the outer flowspec.
			If the outer flowspecs are equal and the tunnel type calls for an
			inner flowspec, then the precedence is determined by comparing inner
			AFI as an unsigned integer with the inner AFI having the smaller
			magnitude having precedence.
			If the inner AFIs are equal, precedence is determined by comparing
			the inner flow specifications.
			INTERNET-DRAFT BGP Tunnel Flow-Spec
			4. Flow Spec Validation
			Flow-specs received over AFI=1/SAFI=TBD1 or AFI=2/SFAI=TBD1 are
			validated, using only the outer Flow-spec, against routing
			reachability received over AFI=1/SAFI=133 and AFI=2/SAFI=133
			respectively, as modified by [FlowSpecOID].
			5. Security Considerations
	No new security issues are introduced to the BGP protocol by this		No new security issues are introduced to the BGP protocol by this
	specification.		specification.
	5. IANA Considerations		6. IANA Considerations
	IANA is requested to assign three new values in the "Flow Spec		IANA is requested to assign a new SAFI as follows:
			Value Description Reference
			----- ------------------------------------------ ---------------
			TBD1 Tunneled traffic flow specification rules [This document]
			IANA is requested to assign two new values in the "Flow Spec
	Component Types" registry as follows:		Component Types" registry as follows:
	Type Name Reference		Type Name Reference
	---- -------------- ---------		---- -------------- ---------
	TBD1 Delimiter type [this document]
	TBD2 VN ID [this document]		TBD2 VN ID [this document]
	TBD3 Flow ID [this document]		TBD3 Flow ID [this document]
			TBD4 Session [this document]
			TBD5 Cookie [this document]
			TBD6 VXLAN-GPE Flags [this document]
	INTERNET-DRAFT NVO3 BGP Flow-Spec		INTERNET-DRAFT BGP Tunnel Flow-Spec
	Normative References		Normative References
	[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, DOI 10.17487/RFC2119,		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119,
	March 1997, <https://www.rfc-editor.org/info/rfc2119>.		March 1997, <https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC2890] - Dommety, G., "Key and Sequence Number Extensions to GRE",
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May		RFC 2890, DOI 10.17487/RFC2890, September 2000,
	2017, <https://www.rfc-editor.org/info/rfc8174>.		<https://www.rfc-editor.org/info/rfc2890>.
	[GENEVE] - J. Gross, T. Sridhar, etc, "Geneve: Generic Network
	Virtualization Encapsulation", draft-ietf-nvo3-geneve, work in
	progress.
	[GUE] - T. Herbert, L. Yong, O. Zia, "Generic UDP Encapsulation",
	draft-ietf-nvo3-gue, work in progress.
	[RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D.,
	Bacher, M., "Dissemination of Flow Specification Rules", draft-
	ietf-idr-rfc5575bis-17, Work in progress, January 2019.
	Informative References		[RFC3931] - Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed.,
			"Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
			DOI 10.17487/RFC3931, March 2005, <https://www.rfc-
			editor.org/info/rfc3931>.
	[RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,		[RFC7348] - Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "Virtual		L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
	eXtensible Local Area Network (VXLAN): A Framework for		eXtensible Local Area Network (VXLAN): A Framework for
	Overlaying Virtualized Layer 2 Networks over Layer 3 Networks",		Overlaying Virtualized Layer 2 Networks over Layer 3 Networks",
	RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-		RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-
	editor.org/info/rfc7348>.		editor.org/info/rfc7348>.
	[RFC7367] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network		[RFC7637] - Garg, P., Ed., and Y. Wang, Ed., "NVGRE: Network
	Virtualization Using Generic Routing Encapsulation", RFC 7637,		Virtualization Using Generic Routing Encapsulation", RFC 7637,
	DOI 10.17487/RFC7637, September 2015, <https://www.rfc-		DOI 10.17487/RFC7637, September 2015, <https://www.rfc-
	editor.org/info/rfc7637>.		editor.org/info/rfc7637>.
	[RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.		[RFC8174] - Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	Narten, "An Architecture for Data-Center Network Virtualization		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
	over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December		2017, <https://www.rfc-editor.org/info/rfc8174>.
	2016, <https://www.rfc-editor.org/info/rfc8014>.
	[IPv6-FlowSpec] - R. Raszuk, etc, "Dissemination of Flow
	Specification Rules for IPv6", draft-ietf-idr-flow-spec-v6,
	work in progress.
	[Layer2-FlowSpec] - W. Hao, etc, "Dissemination of Flow Specification		[FlowSpecL2] - W. Hao, etc, "Dissemination of Flow Specification
	Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in		Rules for L2 VPN", draft-ietf-idr-flowspec-l2vpn, work in
	progress.		progress.
	INTERNET-DRAFT NVO3 BGP Flow-Spec		[FlowSpecOID] - J. Uttaro, J. Alcaide, C. Filsfils, D. Smith, P.
			Mohapatra, "Revised Validation Procedure for BGP Flow
			Specifications", draft-ietf-idr-bgp-flowspec-oid, work in
			progress.
			[FlowSpecV6] - R. Raszuk, etc, "Dissemination of Flow Specification
			Rules for IPv6", draft-ietf-idr-flow-spec-v6, work in progress.
			[RFC5575bis] - Hares, S., Loibl, C., Raszuk, R., McPherson, D.,
			Bacher, M., "Dissemination of Flow Specification Rules", draft-
			ietf-idr-rfc5575bis-17, Work in progress, January 2019.
			INTERNET-DRAFT BGP Tunnel Flow-Spec
			Informative References
			[RFC8014] - Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T.
			Narten, "An Architecture for Data-Center Network Virtualization
			over Layer 3 (NVO3)", RFC 8014, DOI 10.17487/RFC8014, December
			2016, <https://www.rfc-editor.org/info/rfc8014>.
	[GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft-		[GPE] - P. Quinn, etc, "Generic Protocol Extension for VXLAN", draft-
	ietf-nvo3-vxlan-gpe, work in progress.		ietf-nvo3-vxlan-gpe, work in progress.
	INTERNET-DRAFT NVO3 BGP Flow-Spec		INTERNET-DRAFT BGP Tunnel Flow-Spec
	Acknowledgments		Acknowledgments
	The authors wish to acknowledge the important contributions of Jeff		The authors wish to acknowledge the important contributions of Jeff
	Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, and Lucy Yong.		Haas, Susan Hares, Qiandeng Liang, Nan Wu, Yizhou Li, Robert Raszuk,
			and Lucy Yong.
	Authors' Addresses		Authors' Addresses
	Donald Eastlake		Donald Eastlake
	Futurewei Technologies		Futurewei Technologies
	1424 Pro Shop Court		2386 Panoramic Circle
	Davenport, FL 33896 USA		Apopka, FL 32703 USA
	Tel: +1-508-333-2270		Tel: +1-508-333-2270
	Email: d3e3e3@gmail.com		Email: d3e3e3@gmail.com
	Weiguo Hao		Weiguo Hao
	Huawei Technologies		Huawei Technologies
	101 Software Avenue,		101 Software Avenue,
	Nanjing 210012 China		Nanjing 210012 China
	Email: haoweiguo@huawei.com		Email: haoweiguo@huawei.com
	skipping to change at page 12, line 5 ¶		skipping to change at page 17, line 5 ¶
	Huawei Bld., No.156 Beiqing Rd.		Huawei Bld., No.156 Beiqing Rd.
	Beijing 100095 China		Beijing 100095 China
	Email: lizhenbin@huawei.com		Email: lizhenbin@huawei.com
	Rong Gu		Rong Gu
	China Mobile		China Mobile
	Email: gurong_cmcc@outlook.com		Email: gurong_cmcc@outlook.com
	INTERNET-DRAFT NVO3 BGP Flow-Spec		INTERNET-DRAFT BGP Tunnel Flow-Spec
	Copyright, Disclaimer, and Additional IPR Provisions		Copyright, Disclaimer, and Additional IPR Provisions
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
End of changes. 64 change blocks.
	227 lines changed or deleted		438 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/