Huawei

wutianhao10@huawei.com

Huawei

jack.gejun@huawei.com

Huawei

dingxiangfeng@huawei.com

Huawei

rainsword.wang@huawei.com

BGP Flowspec mechanism (BGP-FS) propagates both traffic Flow Specifications and Traffic Filtering Actions by making use of the BGP NLRI and the BGP Extended Community encoding formats. This document specifies a new BGP-FS component type to support community-level filtering. The match field is the community of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

BGP Flow Specification (BGP-FS) defines a new BGP NLRI to distribute traffic flow specification rules via BGP (). BGP-FS policies have a match condition that may be n-tuple match in a policy, and an action that modifies the packet and forwards/drops the packet. Via BGP, new filter rules can be sent to all BGP peers simultaneously without changing router configuration, and the BGP peer can install these routes in the forwarding table. BGP-FS defines Network Layer Reachability Information (NLRI) format used to distribute traffic flow specification rules. NLRI (AFI=1, SAFI=133) is for IPv4 unicast filtering. NLRI (AFI=1, SAFI=134) is for BGP/MPLS VPN filtering. extends the flow-spec rules for layer 2 Ethernet packets. This document specifies a new BGP-FS component type to support community-level filtering. The match field is the community of the destination IP address that is encoded in the Flowspec NLRI. This function is applied in a single administrative domain.

FS: Flow Specification Destination-IP-Community: The community of the destination IP address

This document proposes a new flow specification component type that is encoded in the BGP Flowspec NLRI. The following new component type is defined. Destination-IP-Community Type TBD1 - Destination-IP-Community Encoding: <type (1 octet), [op, value]+> Contains a set of {operator, value} pairs that are used to match the Destination-IP-Community (i.e. the community of the destination IP address). The operator byte is encoded as:

Where: e - end-of-list bit. Set in the last {op, value} pair in the list. a - AND bit. If unset, the previous term is logically ORed with the current one. If set, the operation is a logical AND. It MUST be unset in the Destination-IP-Community filter. len - The length of the value field for this operator given as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), and 8 (len=11) octets. lt - less than comparison between data and value. gt - greater than comparison between data and value. eq - equality between data and value. The bits lt, gt, and eq can be combined to produce match the Destination-IP-Community filter or a range of Destination-IP-Community filter(e.g. less than community 1 and greater than community 2). The value field is encoded as:

Per section 10 of , If a receiving BGP speaker cannot support this new Flow Specification component type, it MUST discard the NLRI value field that contains such unknown components. Since the NLRI field encoding (Section 4 of ) is defined in the form of a 2-tuple <length, NLRI value>, message decoding can skip over the unknown NLRI value and continue with subsequent remaining NLRI.

This section describes how to use this function in a simple scenario. Considering the topology shown in Figure 3 ("Comm" is short for "Community"). In AS64597's R1, if the ISP AS64597 wants to redirect all packets originating from IP Prefix 61 to AS64598 and AS64599: "first go to R3", the ISP AS64597 can use the traditional method or the method defining in this draft.

Using the traditional method, the ISP AS64597 needs to setup multiple "Destination Prefix + Source Prefix" rules in Router R1 as following:

Using the method defining in this draft, the ISP AS64597 needs to setup only one "Destination Community + Source Prefix" rule in Router R1 as following:

Obviously, the new method defining in this draft saves a lot of entry spaces on the control plane and forwarding plane, and it would greatly simplify the operation of the control plane, and the more destination prefixes with the same community has, the more obvious the benefit.

IANA is requested to a new entry in "Flow Spec component types registry" with the following values:

No new security issues are introduced to the BGP protocol by this specification.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification. This document obsoletes both RFC 5575 and RFC 7674. "Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets. This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry. Huawei Technologies Futurewei Technologies Cisco Systems, Inc. Huawei Technologies This document defines a Border Gateway Protocol (BGP) Flow Specification (flowspec) extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering rules either by themselves or in conjunction with L3 flowspecs. AFI/ SAFI 6/133 and 25/134 are used for these purposes. New component types and two extended communities are also defined.