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/