Destination-IP-Community Filter for BGP Flow Specification

BGP Flow Specification (BGP-FS) defines a BGP NLRI mechanism to distribute traffic flow filtering rules via BGP . BGP-FS policies contain match conditions (which can be n-tuple packet header matches) and corresponding actions that modify, forward, or drop matching traffic. Using BGP, filtering rules can be dynamically distributed to network elements without requiring manual device reconfiguration. BGP-FS defines Network Layer Reachability Information (NLRI) formats for IPv4 unicast (AFI=1, SAFI=133) and BGP/MPLS VPNs (AFI=1, SAFI=134). In large-scale networks, configuring individual Flowspec rules based on explicit destination IP prefix matches can lead to severe TCAM and control-plane entry scale bottlenecks. This document specifies a new BGP-FS component type to support community-level filtering. The match field targets the BGP Community attribute of the destination IP prefix. This functionality is designed to operate within a single administrative domain.

FS: Flow Specification Destination-IP-Community: The BGP Standard Community [RFC1997] or Extended Community associated with the reachability route of the destination IP address.

This document defines a new Flow Specification component type encoded within the BGP Flowspec NLRI. Type TBD1: Destination-IP-Community Encoding: <type (1 octet), [op, value]+> This component contains a set of {operator, value} pairs used to match the Destination-IP-Community associated with the destination prefix. The operator byte (numeric_op) is encoded as defined in Section 4.2.1 of :

Where: e - End-of-list bit. Set in the last {op, value} pair. a - AND bit. If unset, the logical operation with the previous term is OR. If set, the operation is AND. For the Destination-IP-Community filter, the 'a' bit MUST be unset (0) unless matching multi-value community sets. len - Length of the value field encoded as (1 << len). Valid lengths for Standard BGP Communities are 4 octets (len=10). Future extensions MAY support 8 octets (Extended) or 12 octets (Large Communities). lt - Less-than comparison between target data and value. gt - Greater-than comparison between target data and value. eq - Equality comparison between target data and value. The comparison operators (lt, gt, eq) can be combined to evaluate a specific community or a range of communities. The value field is encoded as:

Per Section 10 of , if a receiving BGP speaker does not support this component type, it MUST discard the entire NLRI value containing the unknown component. Because the NLRI encoding uses a 2-tuple <length, NLRI value> structure, parsing engines can skip the unknown NLRI value and continue processing subsequent NLRIs.

The implementation of Destination-IP-Community filtering relies on a cross-coupling mechanism between the Unicast BGP Forwarding Table (FIB) and the Flowspec Packet Inspection Engine. The detailed processing workflow is defined in the following three steps: Control-Plane Community Dissemination and FIB Tagging: When a BGP speaker receives unicast BGP routes carrying BGP Communities (e.g., Standard, Extended, or Large Communities), and those routes are selected as best paths and installed into the Forwarding Information Base (FIB), the local system MUST preserve the associated BGP Community attributes (or a local mapped metadata tag representing the Community) within the corresponding FIB entries. For example: FIB Entry for Destination Prefix A: Tagged with Community 64597:1 FIB Entry for Destination Prefix B: Tagged with Community 64597:2 Flowspec Rule Installation: When a BGP Flowspec rule containing the Destination-IP-Community component is received, the system programs a filtering rule into the forwarding hardware. The match parameters include both standard RFC 8955/8956 n-tuples (e.g., Destination IP, Source IP, Protocol, Port) and the target Community value specified in the Destination-IP-Community component (denoted as COMM_Rule, e.g., 64597:1). Datapath Two-Stage Packet Matching: Upon receiving a data packet: The device evaluates the packet against installed Flowspec rules. If a candidate rule contains a Destination-IP-Community match condition, the forwarding engine performs a FIB lookup using the packet's Destination IP address to extract the associated FIB entry's Community attribute (denoted as COMM_FIB). Evaluation: If COMM_FIB matches COMM_Rule (e.g., both are 64597:1), the Destination-IP-Community match condition is satisfied, and the configured Flowspec action (e.g., redirect, drop, rate-limit) is executed. If COMM_FIB does not match COMM_Rule (e.g., COMM_FIB is 64597:2 while COMM_Rule is 64597:1), the match condition fails, and packet processing continues to subsequent rules or default forwarding.

This section illustrates a representative operational scenario for community-level traffic steering. Consider the topology in .

In AS64597, ISP operator policy requires redirecting all traffic from IP Prefix 61 bound for AS64598 and AS64599 to traverse R3 first. Using traditional BGP Flowspec rules, router R1 requires multiple "Destination Prefix + Source Prefix" filter entries:

Using the Destination-IP-Community filter defined in this document, the operator configures a single "Destination Community + Source Prefix" rule on R1:

This mechanism significantly reduces control-plane propagation state and hardware TCAM resource usage on network processors.

IANA is requested to allocate a new component type entry in the "Flow Spec Component Types" registry under the "BGP Flow Spec NLRIs" registry group:

This specification extends BGP Flowspec NLRI matching capabilities. Unauthorized injection or modification of Destination-IP-Community Flowspec rules could lead to traffic misdirection, unexpected dropping, or Denial-of-Service (DoS) conditions. To mitigate these risks: This feature MUST be restricted to a single administrative domain or strictly trusted peer boundaries. BGP speakers MUST filter or strip this Flowspec component type at eBGP domain boundaries unless explicitly allowed by bilateral policy. Standard BGP Flowspec validation procedures [RFC8955] MUST be enforced to prevent unauthorized prefix rule propagation.

The following people made significant contributions to this document:

TBD.