IDR Working Group T. Wu Internet-Draft H. Wang Intended status: Standards Track S. Zhuang Expires: 16 April 2027 J. Dong Huawei 13 October 2026 Destination-IP-Community Filter for BGP Flow Specification draft-wu-idr-flowspec-dip-community-filter-05 Abstract BGP Flow Specification Version 2 (FSv2) propagates both traffic Flow Specifications and Traffic Filtering Actions using an extensible TLV- based filter family architecture. This document specifies a new FSv2 component type under the Routing Filter Family to support community- level filtering. The match condition evaluates the BGP Community attribute associated with the destination IP address encoded in the Flowspec NLRI. This mechanism is intended for deployment within a single administrative domain. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 16 April 2027. Wu, et al. Expires 16 April 2027 [Page 1] Internet-Draft Destination-IP-Community Filter October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Definitions and Acronyms . . . . . . . . . . . . . . . . . . 3 3. Flow Specification Version 2 Encoding for Destination-IP-Community Filter . . . . . . . . . . . . . 3 3.1. Operational and Processing Mechanism . . . . . . . . . . 4 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction BGP [RFC4271] Flow Specification, originally defined in [RFC8955] [RFC8956], has evolved to Flow Specification Version 2 (FSv2) as specified in [I-D.ietf-idr-fsv2-ip-basic]. FSv2 introduces an extensible, TLV-based filter family architecture with explicit rule ordering and modular components. 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 FSv2 component type under the Routing Filter Family 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. Wu, et al. Expires 16 April 2027 [Page 2] Internet-Draft Destination-IP-Community Filter October 2026 2. Definitions and Acronyms * FSv2: Flow Specification Version 2 * Destination-IP-Community: The BGP Standard Community [RFC1997] associated with the reachability route of the destination IP address. 3. Flow Specification Version 2 Encoding for Destination-IP-Community Filter This document defines a new FSv2 component encoded within the Routing Filter Family (Type 1400). Unlike legacy FSv1 raw byte streams, FSv2 utilizes explicit TLV formatting. This document defines a new Flow Specification component type encoded within the BGP Flowspec NLRI. * Filter Family: 1400 (Routing Filter Family) * Component Type: 300 (DIP COM) Encoding format for the DIP COM component: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Type (300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <[numeric_op, Destination-IP-Community]+> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Destination-IP-Community Filter Where: * Flags (4 bits): Defined in FSv2 specifications. * Type (12 bits): Set to 300 for DIP COM. * Length (16 bits): Length of the value field in octets. * <[numeric_op, Destination-IP-Community]+>: Contains a list of {numeric_op, Destination-IP-Community} pairs that are used to match the Destination-IP-Community. Wu, et al. Expires 16 April 2027 [Page 3] Internet-Draft Destination-IP-Community Filter October 2026 - numeric_op: This component uses the Numeric Operator (numeric_op) described in Section 4.1.1 of [I-D.ietf-idr-fsv2-ip-basic], Type 300 component values SHOULD be encoded as 4 octets (numeric_op len=10). - Destination-IP-Community (32 bits): BGP Community value to match. 3.1. Operational and Processing Mechanism 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: 1. Control-Plane Community Dissemination and FIB Tagging: When a BGP speaker receives unicast BGP routes carrying BGP Communities (e.g., Standard 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 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). 3. Datapath Two-Stage Packet Matching: Upon receiving a data packet: a. The device evaluates the packet against installed Flowspec rules. Wu, et al. Expires 16 April 2027 [Page 4] Internet-Draft Destination-IP-Community Filter October 2026 b. 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). c. 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. 4. Use Cases This section illustrates a representative operational scenario for community-level traffic steering. Consider the topology in Figure 2. +---------+ | BGP FS | | Server | +----|----+ | | / / ************/************ * / * IP Prefix 61 * / AS64597 * IP Prefix 81 (Comm 1:1) * / * IP Prefix 82 (Comm 1:1) +-------+ * +---+/ +---+ * +-------+ |AS64596+--------+ R1+---------+ R2|-------+AS64598| +-------+ * +-+-+\ +---+ */ +-------+ * \ |\ / * \ | \ /* * \ | /\* * \ | / \ IP Prefix 91 (Comm 1:1) * \ |/ *\ IP Prefix 92 (Comm 1:1) * \ +-+-+ * \ +-------+ * \-+ R3+-------+AS64599| * +---+ * +-------+ * * ************************* Wu, et al. Expires 16 April 2027 [Page 5] Internet-Draft Destination-IP-Community Filter October 2026 Figure 2: Traffic Redirection Topology using Flowspec 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: +--------------+--------------+-------------------------+ | Destination | Source Prefix| Redirect to IP Nexthop | | Prefix | | | +--------------+--------------+-------------------------+ | IP Prefix 81 | IP Prefix 61 | R3 | +--------------+--------------+-------------------------+ | IP Prefix 82 | IP Prefix 61 | R3 | +--------------+--------------+-------------------------+ | IP Prefix 91 | IP Prefix 61 | R3 | +--------------+--------------+-------------------------+ | IP Prefix 92 | IP Prefix 61 | R3 | +--------------+--------------+-------------------------+ | More prefixes... | +--------------+--------------+-------------------------+ Figure 3: Traditional Flowspec Redirection Rules Using the Destination-IP-Community filter defined in this document, the operator configures a single "Destination Community + Source Prefix" rule on R1: +--------------+--------------+-------------------------+ | Destination | Source Prefix| Redirect to IP Nexthop | | Community | | | +--------------+--------------+-------------------------+ | 1:1 | IP Prefix 61 | R3 | +--------------+--------------+-------------------------+ Figure 4: Community-Level Flowspec Redirection Rule This mechanism significantly reduces control-plane propagation state and hardware TCAM resource usage on network processors. 5. IANA Considerations IANA is requested to make the following allocations under the BGP Flow Specification Version 2 (FSv2) registries defined in [I-D.ietf-idr-fsv2-ip-basic]: Wu, et al. Expires 16 April 2027 [Page 6] Internet-Draft Destination-IP-Community Filter October 2026 FSv2 Routing Filter Family Component Types Registry: +------+------------------------------------+---------------+ | Type | Description | Reference | +------+------------------------------------+---------------+ | 300 | DIP COM (Destination-IP-Community) | This document | +------+------------------------------------+---------------+ 6. Security Considerations This specification extends BGP Flow Specification Version 2 (FSv2) matching capabilities. All security considerations defined in [I-D.ietf-idr-fsv2-ip-basic] apply. 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 MUST be enforced to prevent unauthorized prefix rule propagation. 7. Contributors The following people made significant contributions to this document: Jun Ge Huawei Technologies Email: jack.gejun@huawei.com Xiangfeng Ding Huawei Technologies Email: dingxiangfeng@huawei.com 8. Acknowledgements TBD. 9. References 9.1. Normative References Wu, et al. Expires 16 April 2027 [Page 7] Internet-Draft Destination-IP-Community Filter October 2026 [I-D.ietf-idr-fsv2-ip-basic] Hares, S., Eastlake, D. E., Dong, J., Yadlapalli, C., Maduschke, S., and J. Haas, "BGP Flow Specification Version 2 - for Basic IP", Work in Progress, Internet- Draft, draft-ietf-idr-fsv2-ip-basic-08, 28 September 2026, . [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, . [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, . 9.2. Informative References [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . Authors' Addresses Tianhao Wu Huawei Email: wutianhao10@huawei.com Haibo Wang Huawei Email: rainsword.wang@huawei.com Wu, et al. Expires 16 April 2027 [Page 8] Internet-Draft Destination-IP-Community Filter October 2026 Shunwan Zhuang Huawei Email: zhuangshunwan@huawei.com Jie Dong Huawei 156 Beiqing Road Beijing 100095 P.R. China Email: jie.dong@huawei.com Wu, et al. Expires 16 April 2027 [Page 9]