| Internet-Draft | FlowSpec Bitwise IP Filters | February 2025 |
| Kao | Expires 23 August 2025 | [Page] |
This draft introduces the bitwise matching filters for source or destination IPv4/IPv6 address fields. These filters enhance the functionalities of the BGP Flow Specification framework and aid scenarios involving symmetric traffic load balancing.¶
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 23 August 2025.¶
Copyright (c) 2025 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.¶
Symmetric paths for both directions are required to allow session inspecting service instances (such as the deep packet inspection(DPI) or the firewall service instances) to process the traffic correctly. If a single instance cannot handle the traffic load, symmetric load balancing between multiple inspecting service instances is needed.¶
Hash-based load balancing may not be suitable for this purpose since the order of fields for the hashing mechanism may not be configurable, and different vendors implement different proprietary hashing functions. In a multi-vendor environment, it is desirable to load-balance traffic between each instance using a standardized approach.¶
The BGP Flow Specification(BGP-FS) Network Layer Reachability Information(NLRI) is a standardized approach to distributing traffic filters via BGP. The BGP Flow Specification version 2(FSv2) defined in [I-D.ietf-idr-fsv2-ip-basic] enhances BGP-FS, allowing user-defined order of filters. The Extended IP Filters defined in [I-D.hares-idr-fsv2-more-ip-filters] further extend the filter types of FSv2.¶
This draft defines the bitwise matching filters for source or destination IPv4/IPv6 address fields. We can achieve dynamic symmetric traffic load-balancing using these filters.¶
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.¶
This section defines the bitwise address filter component Sub-TLVs for FSv2. These Sub-TLVs are classified as "IP Extended Filters" as defined in Section 2.5 of [I-D.hares-idr-fsv2-more-ip-filters]. Sub-TLVs for both source and destination address fields are defined.¶
This section describes the procedures for sorting the Sub-TLVs defined in this draft of the same type.¶
The Sub-TLV of the same type with different values can appear multiple times in the same NLRI. The address field is a match if it matches any instances that appear in the NLRI. When sending multiple instances of the Sub-TLV of the same type, the following rules apply:¶
When comparing two NLRIs with the same type of Sub-TLV, the following rules apply:¶
This section describes various use cases for these filters.¶
Referring to Figure 1, service instances SVC0, SVC1, SVC2, and SVC3 need to process both directions of traffic in the same session. Any single service instance cannot handle the traffic volume alone.¶
+------+ +--------+ +------+
| |---| SVC0 |---| |
| | +--------+ | |
| | +--------+ | |
| |---| SVC1 |---| |
|Router| +--------+ |Router|
| X | +--------+ | Y |
| |---| SVC2 |---| |
| | +--------+ | |
| | +--------+ | |
| |---| SVC3 |---| |
+------+ +--------+ +------+
Hash-based load balancing may not be suitable for this case since the order of fields for the hashing mechanism may not be configurable, and different vendors implement different proprietary hashing functions.¶
Deploying bitwise address filters is a viable multi-vendor solution in this case. For example, we can deploy:¶
On X:¶
On Y:¶
The matched traffic is directed to a specific service instance by various mechanisms, such as(but not limited to) the following:¶
We can load balance while keeping the traffic of the same session on the same service instance using these rules.¶
Consider the same example depicted in Figure 1 . If the traffic load drops and we want to scale down the service by shutting down SVC2 and SVC3 to reduce costs, we can deploy new rules:¶
On X:¶
On Y:¶
We can remove the old rules and then shut down SVC2 and SVC3 after the new rules are activated.¶
This section compares the proposed solution with other existing approaches.¶
In [RFC8955], [RFC8956], and [I-D.ietf-idr-fsv2-ip-basic] only IPv4/IPv6 longest-prefix-matching(LPM) filters(Sub-TLV Type 1 and 2) are defined, which cannot match discontiguous bits. These filters may not be suitable for use cases described in Section 3.1 without real-time traffic monitoring mechanisms for every possible source/destination prefix. The manageability and flexibility are not as good as the proposed solution either.¶
If both the LPM and bitwise matching are needed, using the bitwise matching filter is recommended since it provides both functionalities in the same filter. If only LPM is needed, using filters defined in [RFC8955], [RFC8956], or [I-D.ietf-idr-fsv2-ip-basic] is more efficient and recommended.¶
The content filter defined in [I-D.cui-idr-content-filter-flowspec] also provides the bitwise matching capability. Although the filter supports bitwise matching against any position in the packet, address matching is not its primary design goal. Manual calculation of offsets is required to use this filter. Therefore, it may not be suitable for scenarios that match address fields only.¶
With the following conditions met, traditional hash-based ECMP may be used for the scenario described in Section 3.1 .¶
Even with all conditions met, we cannot determine which member a specific packet passes through unless the router provides an interface to query that.¶
Therefore, the bitwise matching filter-based solution is more suitable for this scenario.¶
IANA is requested to indicate [this draft] as a reference on the following assignments in the Flow Specification Component Types Registry:¶
| Type Value | IPv4 Name | IPv6 Name | Reference |
|---|---|---|---|
| TBD1 | Bitwise Destination IPv4 Address Filter | Bitwise Destination IPv6 Address Filter | [this draft] |
| TBD2 | Bitwise Source IPv4 Address Filter | Bitwise Source IPv6 Address Filter | [this draft] |
No new security issues are introduced to the BGP protocol by this specification.¶
TBD¶