draft-ietf-idr-flowspec-l2vpn-16.txt		draft-ietf-idr-flowspec-l2vpn-17.txt
	INTERNET-DRAFT W. Hao		INTERNET-DRAFT W. Hao
	Intended Status: Proposed Standard Huawei Technologies		Intended Status: Proposed Standard Huawei Technologies
	D. Eastlake		D. Eastlake
	Futurewei Technologies		Futurewei Technologies
	S. Litkowski		S. Litkowski
	Cisco Systems		Cisco Systems
	S. Zhuang		S. Zhuang
	Huawei Technologies		Huawei Technologies
	Expires: May 15, 2021 November 16, 2020		Expires: November 11, 2021 May 12, 2021
	BGP Dissemination of L2 Flow Specification Rules		BGP Dissemination of L2 Flow Specification Rules
	draft-ietf-idr-flowspec-l2vpn-16		draft-ietf-idr-flowspec-l2vpn-17
	Abstract		Abstract
	This document defines a Border Gateway Protocol (BGP) Flow		This document defines a Border Gateway Protocol (BGP) Flow
	Specification (flowspec) extension to disseminate Ethernet Layer 2		Specification (flowspec) extension to disseminate Ethernet Layer 2
	(L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering		(L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering
	rules either by themselves or in conjunction with L3 flowspecs.		rules either by themselves or in conjunction with L3 flowspecs.
	AFI/SAFI 6/133 and 25/134 are used for these purposes. New component		AFI/SAFI 6/133 and 25/134 are used for these purposes. New component
	types and an extended community also are defined.		types and an extended community also are defined.
	Status of This Document		Status of This Document
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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		https://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.		https://www.ietf.org/shadow.html.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	Table of Contents		Table of Contents
	1. Introduction............................................3		1. Introduction............................................3
	1.1 Terminology............................................4		1.1 Terminology............................................4
	2. Layer 2 Flow Specification Encoding.....................5		2. Layer 2 Flow Specification Encoding.....................5
	2.1 L2 Component Types.....................................6		2.1 L2 Component Types.....................................6
	skipping to change at page 3, line 9 ¶		skipping to change at page 3, line 9 ¶
	Normative References......................................20		Normative References......................................20
	Informative References....................................21		Informative References....................................21
	Authors' Addresses........................................22		Authors' Addresses........................................22
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	1. Introduction		1. Introduction
	Border Gateway Protocol (BGP) Flow Specification [RFC5575bis]		Border Gateway Protocol (BGP) Flow Specification [RFC8955] (flowspec)
	(flowspec) is an extension to BGP that supports the dissemination of		is an extension to BGP that supports the dissemination of traffic
	traffic flow specification rules and actions to be taken on packets		flow specification rules and actions to be taken on packets in a
	in a specified flow. It leverages the BGP Control Plane to simplify		specified flow. It leverages the BGP Control Plane to simplify the
	the distribution of ACLs (Access Control Lists). Using the Flow		distribution of ACLs (Access Control Lists). Using the Flow
	Specification extension new filter rules can be injected to all BGP		Specification extension new filter rules can be injected to all BGP
	peers simultaneously without changing router configuration. A		peers simultaneously without changing router configuration. A
	typical application is to automate the distribution of traffic filter		typical application is to automate the distribution of traffic filter
	lists to routers for DDoS (Distributed Denial of Service) mitigation,		lists to routers for DDoS (Distributed Denial of Service) mitigation,
	access control, and similar applications.		access control, and similar applications.
	BGP Flow Specification [RFC5575bis] defines a BGP Network Layer		BGP Flow Specification [RFC8955] defines a BGP Network Layer
	Reachability Information (NLRI) format used to distribute traffic		Reachability Information (NLRI) format used to distribute traffic
	flow specification rules. The NLRI for (AFI=1, SAFI=133) specifies		flow specification rules. The NLRI for (AFI=1, SAFI=133) specifies
	IPv4 unicast filtering. The NLRI for (AFI=1, SAFI=134) specifies		IPv4 unicast filtering. The NLRI for (AFI=1, SAFI=134) specifies
	IPv4 BGP/MPLS VPN filtering [RFC7432]. The Flow Specification match		IPv4 BGP/MPLS VPN filtering [RFC7432]. The Flow Specification match
	part defined in [RFC5575bis] only includes L3/L4 information like		part defined in [RFC8955] only includes L3/L4 information like IPv4
	IPv4 source/destination prefix, protocol, ports, and the like, so		source/destination prefix, protocol, ports, and the like, so traffic
	traffic flows can only be filtered based on L3/L4 information. This		flows can only be filtered based on L3/L4 information. This has been
	has been extended by [FlowSpecV6] to cover IPv6 (AFI=2) L3/L4.		extended by [RFC8956] to cover IPv6 (AFI=2) L3/L4.
	Layer 2 Virtual Private Networks (L2VPNs) have been deployed in an		Layer 2 Virtual Private Networks (L2VPNs) have been deployed in an
	increasing number of networks. Such networks also have requirements		increasing number of networks. Such networks also have requirements
	to deploy BGP Flow Specification to mitigate DDoS attack traffic.		to deploy BGP Flow Specification to mitigate DDoS attack traffic.
	Within an L2VPN network, both IP and non-IP Ethernet traffic may		Within an L2VPN network, both IP and non-IP Ethernet traffic may
	exist. For IP traffic filtering, the VPN Flow Specification rules		exist. For IP traffic filtering, the VPN Flow Specification rules
	defined in [RFC5575bis] and/or [FlowSpecV6], which include match		defined in [RFC8955] and/or [RFC8956], which include match criteria
	criteria and actions, can still be used. For non-IP Ethernet traffic		and actions, can still be used. For non-IP Ethernet traffic
	filtering, Layer 2 related information like source/destination MAC		filtering, Layer 2 related information like source/destination MAC
	and VLAN must be considered.		and VLAN must be considered.
	There are different kinds of L2VPN networks like EVPN [RFC7432], BGP		There are different kinds of L2VPN networks like EVPN [RFC7432], BGP
	VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP)		VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP)
	auto discovery [RFC6074]. Because the Flow Specification feature		auto discovery [RFC6074]. Because the Flow Specification feature
	relies on the BGP protocol to distribute traffic filtering rules, it		relies on the BGP protocol to distribute traffic filtering rules, it
	can only be incrementally deployed in those L2VPN networks where BGP		can only be incrementally deployed in those L2VPN networks where BGP
	has already been used for auto discovery and/or signaling purposes		has already been used for auto discovery and/or signaling purposes
	such as BGP-based VPLS [RFC4761], EVPN, and LDP-based VPLS [RFC4762]		such as BGP-based VPLS [RFC4761], EVPN, and LDP-based VPLS [RFC4762]
	with BGP auto-discovery [RFC6074].		with BGP auto-discovery [RFC6074].
	This document defines new flowspec component types and two new		This document defines new flowspec component types and two new
	extended communities to support L2 and L2VPN flowspec applications.		extended communities to support L2 and L2VPN flowspec applications.
	The flowspec rules can be enforced on all border routers or on some		The flowspec rules can be enforced on all border routers or on some
	interface sets of the border routers. SAFI=133 in [RFC5575bis] and		interface sets of the border routers. SAFI=133 in [RFC8955] and
	[FlowSpecV6] is extended for AFI=6 as specified in Section 2 to cover		[RFC8956] is extended for AFI=6 as specified in Section 2 to cover L2
	L2 traffic filtering information and in Section 3 SAFI=134 is		traffic filtering information and in Section 3 SAFI=134 is extended
	extended for AFI=25 to cover the L2VPN environment.		for AFI=25 to cover the L2VPN environment.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	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.
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 9 ¶
	VLAN - Virtual Local Area Network		VLAN - Virtual Local Area Network
	VPLS - Virtual Private Line Service [RFC4762]		VPLS - Virtual Private Line Service [RFC4762]
	VPN - Virtual Private Network		VPN - Virtual Private Network
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	2. Layer 2 Flow Specification Encoding		2. Layer 2 Flow Specification Encoding
	[RFC5575bis] defines SAFI 133 and SAFI 134, with AFI=1, for		[RFC8955] defines SAFI 133 and SAFI 134, with AFI=1, for
	"dissemination of IPv4 flow specification rules" and "dissemination		"dissemination of IPv4 flow specification rules" and "dissemination
	of VPNv4 flow specification rules", respectively. [FlowSpecV6]]		of VPNv4 flow specification rules", respectively. [RFC8956]] extends
	extends [RFC5575bis] to also allow AFI=2 thus making it applicable to		[RFC8955] to also allow AFI=2 thus making it applicable to both IPv4
	both IPv4 and IPv6 applications. This document further extends		and IPv6 applications. This document further extends SAFI=133 for
	SAFI=133 for AFI=6 and SAFI=134 for AFI=25 to make them applicable to		AFI=6 and SAFI=134 for AFI=25 to make them applicable to L2 and L2VPN
	L2 and L2VPN applications. This document also provides for the		applications. This document also provides for the optional
	optional combination of L3 flow specifications with these L2 flow		combination of L3 flow specifications with these L2 flow
	specifications.		specifications.
	This section specifies the L2 flowspec for AFI=6/SAFI=133. To		This section specifies the L2 flowspec for AFI=6/SAFI=133. To
	simplify assignments, a new registry is used for L2 flowspec. Since		simplify assignments, a new registry is used for L2 flowspec. Since
	it is frequently desirable to also filter on L3/L4 fields, provision		it is frequently desirable to also filter on L3/L4 fields, provision
	is made for their inclusion along with an indication of the L3		is made for their inclusion along with an indication of the L3
	protocol involved (IPv4 or IPv6).		protocol involved (IPv4 or IPv6).
	The NLRI part of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as		The NLRI part of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as
	a 1- or 2-octet total NLRI length field followed by several fields as		a 1- or 2-octet total NLRI length field followed by several fields as
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 45 ¶
	+-------------------------------+		+-------------------------------+
	| NLRI-value | variable		| NLRI-value | variable
	+-------------------------------+		+-------------------------------+
	Figure 1: Flow Specification NLRI for L2		Figure 1: Flow Specification NLRI for L2
	The fields show in Figure 1 are further specified below:		The fields show in Figure 1 are further specified below:
	total-length: The length of the subsequent fields (L3 AFI,		total-length: The length of the subsequent fields (L3 AFI,
	L2-length, and NRLI-value) encoded as provided in Section 4.1		L2-length, and NRLI-value) encoded as provided in Section 4.1
	of [RFC5575bis]. If this field is less than 4, which is the		of [RFC8955]. If this field is less than 4, which is the
	minimum valid value, then the NLRI is malformed in which case a		minimum valid value, then the NLRI is malformed in which case a
	NOTIFICATION message is sent and the BGP connection closed as		NOTIFICATION message is sent and the BGP connection closed as
	provided in Section 6.3 of [RFC4271].		provided in Section 6.3 of [RFC4271].
	L3-AFI: If no L3/L4 filtering is desired, this two octet field		L3-AFI: If no L3/L4 filtering is desired, this two octet field
	MUST be zero which is a reserved AFI value. Otherwise L3-AFI		MUST be zero which is a reserved AFI value. Otherwise L3-AFI
	indicates the L3 protocol involved by giving its AFI (0x0001		indicates the L3 protocol involved by giving its AFI (0x0001
	for IPv4 or 0x0002 for IPv6). If the receiver does not		for IPv4 or 0x0002 for IPv6). If the receiver does not
	understand the value of the L3-AFI field, the MP_REACH or		understand the value of the L3-AFI field, the MP_REACH or
	MP_UNREACH attribute is ignored.		MP_UNREACH attribute is ignored.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	L2-length: The length of the L2 components at the beginning of the		L2-length: The length of the L2 components at the beginning of the
	NLRI-value field encoded as provided in Section 4.1 of		NLRI-value field encoded as provided in Section 4.1 of
	[RFC5575bis]. If the value of this field indicates that the L2		[RFC8955]. If the value of this field indicates that the L2
	components extend beyond the total-length, the NLRI is		components extend beyond the total-length, the NLRI is
	malformed in which case a NOTIFICATION message is sent and the		malformed in which case a NOTIFICATION message is sent and the
	BGP connection closed as provided in Section 6.3 of [RFC4271].		BGP connection closed as provided in Section 6.3 of [RFC4271].
	N2-length MAY be zero although, in that case, it would have		N2-length MAY be zero although, in that case, it would have
	been more efficient to encode the attribute as an L3 Flow spec		been more efficient to encode the attribute as an L3 Flow spec
	unless it is desired to apply an L2 action (see Section 4). A		unless it is desired to apply an L2 action (see Section 4). A
	null L2 flowspec always matches.		null L2 flowspec always matches.
	NLRI-value: This consists of the L2 flowspec, of length L2-length,		NLRI-value: This consists of the L2 flowspec, of length L2-length,
	followed by an optionally present L3 flowspec. The result can		followed by an optionally present L3 flowspec. The result can
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	intersection (AND) of all the components except that the		intersection (AND) of all the components except that the
	components in the initial L2 region are interpreted as L2		components in the initial L2 region are interpreted as L2
	components and the remainder as L3 components per the L3-AFI		components and the remainder as L3 components per the L3-AFI
	field. This is necessary because there are different registries		field. This is necessary because there are different registries
	for the L2, L3 IPv4, and L3 IPv6 component types. If the L3		for the L2, L3 IPv4, and L3 IPv6 component types. If the L3
	flowspec is null (length zero), it always matches.		flowspec is null (length zero), it always matches.
	2.1 L2 Component Types		2.1 L2 Component Types
	The L2 flowspec portion of the NLRI-value consists of flowspec		The L2 flowspec portion of the NLRI-value consists of flowspec
	components as in [RFC5575bis] but using L2 components and types as		components as in [RFC8955] but using L2 components and types as
	specified below. All components start with a type octet followed by a		specified below. All components start with a type octet followed by a
	length octet followed by any additional information needed. The		length octet followed by any additional information needed. The
	length octet give the length, in octets, of the information after the		length octet give the length, in octets, of the information after the
	length octet. This structure applies to all new components to be		length octet. This structure applies to all new components to be
	defined in the L2 Flow-spec Component Registry (see Section 6) and to		defined in the L2 Flow-spec Component Registry (see Section 6) and to
	all existing components except Types 2 and 3 where the length is in		all existing components except Types 2 and 3 where the length is in
	bits.		bits.
	2.1.1 Type 1 - Ethernet Type (EtherType)		2.1.1 Type 1 - Ethernet Type (EtherType)
	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 two-		Defines a list of {operation, value} pairs used to match the two-
	octet EtherType field. op is encoded as specified in Section 4.2.1.1		octet EtherType field. op is encoded as specified in Section 4.2.1.1
	of [RFC5575bis]. Values are encoded as 2-octet quantities. Ethernet		of [RFC8955]. Values are encoded as 2-octet quantities. Ethernet II
	II framing defines the two-octet Ethernet Type (EtherType) field in		framing defines the two-octet Ethernet Type (EtherType) field in an
	an Ethernet frame, preceded by destination and source MAC addresses,		Ethernet frame, preceded by destination and source MAC addresses,
	that identifies an upper layer protocol encapsulating the frame data.		that identifies an upper layer protocol encapsulating the frame data.
	The match fails if LLC encoding is being used rather than EtherType		The match fails if LLC encoding is being used rather than EtherType
	encoding.		encoding.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	2.1.2 Type 2 - Source MAC		2.1.2 Type 2 - Source MAC
	Encoding: <type (1 octet), MAC Prefix length (1 octet), MAC Prefix>		Encoding: <type (1 octet), MAC Prefix length (1 octet), MAC Prefix>
	skipping to change at page 7, line 34 ¶		skipping to change at page 7, line 34 ¶
	number of octets. These padding bits are ignored for matching		number of octets. These padding bits are ignored for matching
	purposes.		purposes.
	2.1.4 Type 4 - DSAP (Destination Service Access Point)		2.1.4 Type 4 - DSAP (Destination Service Access Point)
	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 1-octet		Defines a list of {operation, value} pairs used to match the 1-octet
	DSAP in the IEEE 802.2 LLC (Logical Link Control Header). Values are		DSAP in the IEEE 802.2 LLC (Logical Link Control Header). Values are
	encoded as 1-octet quantities. op is encoded as specified in Section		encoded as 1-octet quantities. op is encoded as specified in Section
	4.2.1.1 of [RFC5575bis]. The match fails if EtherType L2 header		4.2.1.1 of [RFC8955]. The match fails if EtherType L2 header encoding
	encoding is being used rather than LLC encoding.		is being used rather than LLC encoding.
	2.1.5 Type 5 - SSAP (Source Service Access Point)		2.1.5 Type 5 - SSAP (Source Service Access Point)
	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 1-octet		Defines a list of {operation, value} pairs used to match the 1-octet
	SSAP in the IEEE 802.2 LLC. Values are encoded as 1-octet		SSAP in the IEEE 802.2 LLC. Values are encoded as 1-octet
	quantities. op is encoded as specified in Section 4.2.1.1 of		quantities. op is encoded as specified in Section 4.2.1.1 of
	[RFC5575bis]. The match fails if EtherType L2 header encoding is		[RFC8955]. The match fails if EtherType L2 header encoding is being
	being used rather than LLC encoding.		used rather than LLC encoding.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	2.1.6 Type 6 - Control field in LLC		2.1.6 Type 6 - Control field in LLC
	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 1-octet		Defines a list of {operation, value} pairs used to match the 1-octet
	control field in the IEEE 802.2 LLC. Values are encoded as 1-octet		control field in the IEEE 802.2 LLC. Values are encoded as 1-octet
	quantities. op is encoded as specified in Section 4.2.1.1 of		quantities. op is encoded as specified in Section 4.2.1.1 of
	[RFC5575bis]. The match fails if EtherType L2 header encoding is		[RFC8955]. The match fails if EtherType L2 header encoding is being
	being used rather than LLC encoding.		used rather than LLC encoding.
	2.1.7 Type 7 - SNAP		2.1.7 Type 7 - SNAP
	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 5-octet SNAP		Defines a list of {operation, value} pairs used to match 5-octet SNAP
	(Sub-Network Access Protocol) field. Values are encoded as 5-octet		(Sub-Network Access Protocol) field. Values are encoded as 5-octet
	quantities. op is encoded as specified in Section 4.2.1.1 of		quantities. op is encoded as specified in Section 4.2.1.1 of
	[RFC5575bis]. The match fails if EtherType L2 header encoding is		[RFC8955]. The match fails if EtherType L2 header encoding is being
	being used rather than LLC encoding.		used rather than LLC encoding.
	2.1.8 Type 8 - VLAN ID		2.1.8 Type 8 - VLAN 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 VLAN ID.		Defines a list of {operation, value} pairs used to match VLAN ID.
	Values are encoded as 2-octet quantities, where the four most		Values are encoded as 2-octet quantities, where the four most
	significant bits are set to zero and ignored for matching and the 12		significant bits are set to zero and ignored for matching and the 12
	least significant bits contain the VLAN value. op is encoded as		least significant bits contain the VLAN value. op is encoded as
	specified in Section 4.2.1.1 of [RFC5575bis].		specified in Section 4.2.1.1 of [RFC8955].
	In the virtual local-area network (VLAN) stacking case, the VLAN ID		In the virtual local-area network (VLAN) stacking case, the VLAN ID
	is the outer VLAN ID.		is the outer VLAN ID.
	2.1.9 Type 9 - VLAN PCP		2.1.9 Type 9 - VLAN PCP
	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 3-bit VLAN		Defines a list of {operation, value} pairs used to match 3-bit VLAN
	PCP (priority code point) fields [802.1Q]. Values are encoded using		PCP (priority code point) fields [802.1Q]. Values are encoded using
	a single octet, where the five most significant bits are set to zero		a single octet, where the five most significant bits are set to zero
	and ignored for matching and the three least significant bits contain		and ignored for matching and the three least significant bits contain
	the VLAN PCP value. op is encoded as specified in Section 4.2.1.1 of		the VLAN PCP value. op is encoded as specified in Section 4.2.1.1 of
	[RFC5575bis].		[RFC8955].
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	In the virtual local-area network (VLAN) stacking case, the VLAN PCP		In the virtual local-area network (VLAN) stacking case, the VLAN PCP
	is part of the outer VLAN tag.		is part of the outer VLAN tag.
	2.1.10 Type 10 - Inner VLAN ID		2.1.10 Type 10 - Inner VLAN 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 inner		Defines a list of {operation, value} pairs used to match the inner
	VLAN ID using for virtual local-area network (VLAN) stacking or Q-in-		VLAN ID using for virtual local-area network (VLAN) stacking or Q-in-
	Q use. Values are encoded as 2-octet quantities, where the four most		Q use. Values are encoded as 2-octet quantities, where the four most
	significant bits are set to zero and ignored for matching and the 12		significant bits are set to zero and ignored for matching and the 12
	least significant bits contain the VLAN value. op is encoded as		least significant bits contain the VLAN value. op is encoded as
	specified in Section 4.2.1.1 of [RFC5575bis].		specified in Section 4.2.1.1 of [RFC8955].
	In the single VLAN case, this component type MUST NOT be used. If it		In the single VLAN case, this component type MUST NOT be used. If it
	appears the match will fail.		appears the match will fail.
	2.1.11 Type 11 - Inner VLAN PCP		2.1.11 Type 11 - Inner VLAN PCP
	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 3-bit inner		Defines a list of {operation, value} pairs used to match 3-bit inner
	VLAN PCP fields [802.1Q] using for virtual local-area network (VLAN)		VLAN PCP fields [802.1Q] using for virtual local-area network (VLAN)
	stacking or Q in Q use. Values are encoded using a single octet,		stacking or Q in Q use. Values are encoded using a single octet,
	where the five most significant bits are set to zero and ignored for		where the five most significant bits are set to zero and ignored for
	matching and the three least significant bits contain the VLAN PCP		matching and the three least significant bits contain the VLAN PCP
	value. op is encoded as specified in Section 4.2.1.1 of [RFC5575bis].		value. op is encoded as specified in Section 4.2.1.1 of [RFC8955].
	In the single VLAN case, this component type MUST NOT be used. If it		In the single VLAN case, this component type MUST NOT be used. If it
	appears the match will fail.		appears the match will fail.
	2.1.12 Type 12 - VLAN DEI		2.1.12 Type 12 - VLAN DEI
	Encoding: <type (1 octet), length (1 octet), op (1 octet)>		Encoding: <type (1 octet), length (1 octet), op (1 octet)>
	This type tests the DEI (Drop Eligible Indicator) bit in the VLAN		This type tests the DEI (Drop Eligible Indicator) bit in the VLAN
	tag. If op is zero, it matches if and only if the DEI bit is zero. If		tag. If op is zero, it matches if and only if the DEI bit is zero. If
	skipping to change at page 10, line 29 ¶		skipping to change at page 10, line 29 ¶
	Encoding: <type (1 octet), length (1 octet), op (1 octet)>		Encoding: <type (1 octet), length (1 octet), op (1 octet)>
	This type tests the bottom nibble of the top octet of the Source MAC		This type tests the bottom nibble of the top octet of the Source MAC
	address. The two low order bits of that nibble have long been the		address. The two low order bits of that nibble have long been the
	local bit (0x2) and the group addressed bit (0x1). However, recent		local bit (0x2) and the group addressed bit (0x1). However, recent
	changes in IEEE 802 have divided the local address space into 4		changes in IEEE 802 have divided the local address space into 4
	quadrants specified by the next two bits (0x4 and 0x8) [RFC7042bis].		quadrants specified by the next two bits (0x4 and 0x8) [RFC7042bis].
	This flowspec component permits testing, for example, that a MAC is		This flowspec component permits testing, for example, that a MAC is
	group addressed or is a local address in a particular quadrant. The		group addressed or is a local address in a particular quadrant. The
	encoding is as given in Section 4.2.1.2 of [RFC5575bis].		encoding is as given in Section 4.2.1.2 of [RFC8955].
	2.1.15 Type 15 - Destination MAC Special Bits		2.1.15 Type 15 - Destination MAC Special Bits
	Encoding: <type (1 octet), length (1 octet), op (1 octet)>		Encoding: <type (1 octet), length (1 octet), op (1 octet)>
	As discussed in Section 2.1.14 but for the Destination MAC Address.		As discussed in Section 2.1.14 but for the Destination MAC Address.
	2.2 Order of Traffic Filtering Rules		2.2 Order of Traffic Filtering Rules
	The existing rules in Section 5.1 of [RFC5575bis] and in [FlowSpecV6]		The existing rules in Section 5.1 of [RFC8955] and in [RFC8956] for
	for the ordering of traffic filtering are extended as follows:		the ordering of traffic filtering are extended as follows:
	L2 flowspecs (AFI = 6, 25) take precedence over L3 flowspecs (AFI =		L2 flowspecs (AFI = 6, 25) take precedence over L3 flowspecs (AFI =
	1, 2). Between two L2 flowspecs, precedence of the L2 portion is		1, 2). Between two L2 flowspecs, precedence of the L2 portion is
	determined as specified in this section after this paragraph. If the		determined as specified in this section after this paragraph. If the
	L2 flowspec L2 portions are the same and the L3-AFI is nonzero, then		L2 flowspec L2 portions are the same and the L3-AFI is nonzero, then
	the L3 portions are compared as specified in [RFC5575bis] or		the L3 portions are compared as specified in [RFC8955] or [RFC8956]
	[FlowSpecV6] as appropriate. Note: if the L3-AFI fields are different		as appropriate. Note: if the L3-AFI fields are different between two
	between two L2 flowspecs, they will never match the same packet so it		L2 flowspecs, they will never match the same packet so it will not be
	will not be necessary to prioritize two flowspecs with different		necessary to prioritize two flowspecs with different L3-AFI values.
	L3-AFI values.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	The original definition for the order of traffic filtering rules can		The original definition for the order of traffic filtering rules can
	be reused for L2 with new consideration for the MAC Address offset.		be reused for L2 with new consideration for the MAC Address offset.
	As long as the offsets are equal, the comparison is the same,		As long as the offsets are equal, the comparison is the same,
	retaining longest-prefix-match semantics. If the offsets are not		retaining longest-prefix-match semantics. If the offsets are not
	equal, the lowest offset has precedence, as this flow matches the		equal, the lowest offset has precedence, as this flow matches the
	most significant bit.		most significant bit.
	skipping to change at page 13, line 11 ¶		skipping to change at page 13, line 11 ¶
	Section 2.2. Note that if the Route Distinguisher is different		Section 2.2. Note that if the Route Distinguisher is different
	between two L2VPN filtering rules, they will never both match the		between two L2VPN filtering rules, they will never both match the
	same packet so they need not be prioritized.		same packet so they need not be prioritized.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	4. Ethernet Flow Specification Traffic Actions		4. Ethernet Flow Specification Traffic Actions
	The default action for an L2 traffic filtering flowspec is to accept		The default action for an L2 traffic filtering flowspec is to accept
	traffic that matches that particular rule. The following extended		traffic that matches that particular rule. The following extended
	community values per [RFC5575bis] can be used to specify particular		community values per [RFC8955] can be used to specify particular
	actions in an L2 VPN network:		actions in an L2 VPN network:
	+--------+--------------------+----------------------------+		+--------+--------------------+----------------------------+
	| type | extended community | encoding |		| type | extended community | encoding |
	+--------+--------------------+----------------------------+		+--------+--------------------+----------------------------+
	| 0x8006 | traffic-rate | 2-octet as#, 4-octet float |		| 0x8006 | traffic-rate | 2-octet as#, 4-octet float |
	| 0x8007 | traffic-action | bitmask |		| 0x8007 | traffic-action | bitmask |
	| 0x8008 | redirect | 6-octet Route Target |		| 0x8008 | redirect | 6-octet Route Target |
	| 0x8009 | traffic-marking | DSCP value |		| 0x8009 | traffic-marking | DSCP value |
	+--------+--------------------+----------------------------+		+--------+--------------------+----------------------------+
	Redirect: The action should be redefined to allow the traffic to be		Redirect: The action should be redefined to allow the traffic to be
	redirected to a MAC or IP VRF routing instance that lists the		redirected to a MAC or IP VRF routing instance that lists the
	specified route-target in its import policy.		specified route-target in its import policy.
	Besides the above extended communities, this document also specifies		Besides the above extended communities, this document also specifies
	the following BGP extended communities for Ethernet flows to extend		the following BGP extended communities for Ethernet flows to extend
	[RFC5575bis]:		[RFC8955]:
	+--------+------------------------+--------------------------+		+--------+------------------------+--------------------------+
	| type | extended community | encoding |		| type | extended community | encoding |
	+--------+------------------------+--------------------------+		+--------+------------------------+--------------------------+
	| TBD1 | VLAN-action | bitmask |		| TBD1 | VLAN-action | bitmask |
	| TBD2 | TPID-action | bitmask |		| TBD2 | TPID-action | bitmask |
	+--------+------------------------+--------------------------+		+--------+------------------------+--------------------------+
	4.1 VLAN-action		4.1 VLAN-action
	skipping to change at page 17, line 9 ¶		skipping to change at page 17, line 9 ¶
	5. Flow Spec Validation		5. Flow Spec Validation
	Flow Specifications received over AFI=25/SAFI=134 are validated		Flow Specifications received over AFI=25/SAFI=134 are validated
	against routing reachability received over AFI=25/SAFI=128 as		against routing reachability received over AFI=25/SAFI=128 as
	modified to conform to [FlowSpecOID].		modified to conform to [FlowSpecOID].
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to change the description for SAFI 134 [RFC5575bis]		IANA is requested to change the description for SAFI 134 [RFC8955] to
	to read as follows and to change the reference for it to [this		read as follows and to change the reference for it to [this
	document]:		document]:
	134 VPN dissemination of flow specification rules		134 VPN dissemination of flow specification rules
	IANA is requested to create an L2 Flow Specification Component Type		IANA is requested to create an L2 Flow Specification Component Type
	registry on the Flow Spec Component Types registries web page as		registry on the Flow Spec Component Types registries web page as
	follows:		follows:
	Name: L2 Flow Specification Component Types		Name: L2 Flow Specification Component Types
	Reference: [this document]		Reference: [this document]
	skipping to change at page 19, line 10 ¶		skipping to change at page 19, line 10 ¶
	Type value Name Reference		Type value Name Reference
	------------ ------------------------ ---------------		------------ ------------------------ ---------------
	TBD1[0x080A] Flow spec VLAN action [this document]		TBD1[0x080A] Flow spec VLAN action [this document]
	TBD2[0x080B] Flow spec TPID action [this document]		TBD2[0x080B] Flow spec TPID action [this document]
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	7. Security Considerations		7. Security Considerations
	For General BGP Flow Specification Security Considerations, see		For General BGP Flow Specification Security Considerations, see
	[RFC5575bis].		[RFC8955].
	VLAN tagging identifies Layer 2 communities which are commonly		VLAN tagging identifies Layer 2 communities which are commonly
	expected to be isolated except when higher layer connection is		expected to be isolated except when higher layer connection is
	provided, such as Layer 3 routing. Thus, the ability of the flowspec		provided, such as Layer 3 routing. Thus, the ability of the flowspec
	VLAN action to change the VLAN ID in a frame might compromise		VLAN action to change the VLAN ID in a frame might compromise
	security.		security.
	8. Acknowledgements		8. Acknowledgements
	The authors wish to acknowledge the important contributions and		The authors wish to acknowledge the important contributions and
	skipping to change at page 20, line 39 ¶		skipping to change at page 20, line 39 ¶
	[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,		[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo,
	"Provisioning, Auto-Discovery, and Signaling in Layer 2		"Provisioning, Auto-Discovery, and Signaling in Layer 2
	Virtual Private Networks (L2VPNs)", RFC 6074, DOI		Virtual Private Networks (L2VPNs)", RFC 6074, DOI
	10.17487/RFC6074, January 2011, <https://www.rfc-		10.17487/RFC6074, January 2011, <https://www.rfc-
	editor.org/info/rfc6074>.		editor.org/info/rfc6074>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
	Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May		Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May
	2017, <https://www.rfc-editor.org/info/rfc8174>.		2017, <https://www.rfc-editor.org/info/rfc8174>.
	[FlowSpecOID] Uttaro, J., Alcaide, J., Filsfils, C. Smith, D.,		[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
	Mohapatra, P., draft-ietf-idr-bgp-flowspec-oid, work in		Bacher, "Dissemination of Flow Specification Rules", RFC
	progress.		8955, DOI 10.17487/RFC8955, December 2020,
			<https://www.rfc-editor.org/info/rfc8955>.
	[FlowSpecV6] McPherson, D., Raszuk, R., Pithawala, B.,		[RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed.,
	akarch@cisco.com, a., and S. Hares, "Dissemination of Flow		"Dissemination of Flow Specification Rules for IPv6", RFC
	Specification Rules for IPv6", draft-ietf-idr-flow-spec-		8956, DOI 10.17487/RFC8956, December 2020,
	v6-10. Work in progress.		<https://www.rfc-editor.org/info/rfc8956>.
	[RFC5575bis] Hares, S., Loibl, C., Raszuk, R., McPherson, D., Bacher,		[FlowSpecOID] Uttaro, J., Alcaide, J., Filsfils, C. Smith, D.,
	M., "Dissemination of Flow Specification Rules", draft-		Mohapatra, P., draft-ietf-idr-bgp-flowspec-oid, work in
	ietf-idr-rfc5575bis, Work in progress.		progress, April 2021.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	Informative References		Informative References
	[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,		[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
	Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based		Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
	Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February		Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
	2015, <https://www.rfc-editor.org/info/rfc7432>.		2015, <https://www.rfc-editor.org/info/rfc7432>.
	[RFC7042bis] Eastlake, D., and J. Abley, "IANA Considerations and		[RFC7042bis] Eastlake, D., and J. Abley, "IANA Considerations and
	IETF Protocol and Documentation Usage for IEEE 802		IETF Protocol and Documentation Usage for IEEE 802
	Parameters", draft-eastlake-rfc7042bis, Work in progress.		Parameters", draft-eastlake-rfc7042bis, work in progress,
			March 2021.
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	Authors' Addresses		Authors' Addresses
	Weiguo Hao		Weiguo Hao
	Huawei Technologies		Huawei Technologies
	101 Software Avenue,		101 Software Avenue,
	Nanjing 210012		Nanjing 210012
	China		China
	skipping to change at page 23, line 9 ¶		skipping to change at page 23, line 9 ¶
	Huawei Bld., No.156 Beiqing Rd.		Huawei Bld., No.156 Beiqing Rd.
	Beijing 100095		Beijing 100095
	China		China
	Email: zhuangshunwan@huawei.com		Email: zhuangshunwan@huawei.com
	INTERNET-DRAFT L2 Flow Spec		INTERNET-DRAFT L2 Flow Spec
	Copyright, Disclaimer, and Additional IPR Provisions		Copyright, Disclaimer, and Additional IPR Provisions
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	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
End of changes. 35 change blocks.
	70 lines changed or deleted		71 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/