| Internet-Draft | BGP Extensions to Enable BGP FlowSpec Ba | July 2025 |
| He, et al. | Expires 2 January 2026 | [Page] |
Border Gateway Protocol (BGP) Flow Specification (FlowSpec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. In-situ Flow Information Telemetry (IFIT) denotes a family of flow- oriented on-path telemetry techniques, which can provide high-precision flow insight and real-time network issue notification. This document defines BGP extensions to distribute BGP FlowSpec based traffic filtering carrying IFIT information. So IFIT behavior can be applied to the specified flow automatically.¶
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 2 January 2026.¶
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.¶
Border Gateway Protocol (BGP) Flow Specification [RFC8955] (FlowSpec) is an extension to BGP that supports the dissemination of traffic flow specifications and resulting actions to be taken on packets in a specified flow. It leverages the BGP Control Plane to simplify the distribution of ACLs (Access Control Lists). Using the Flow Specification extension, new filter rules can be injected to all BGP peers simultaneously without changing router configuration.¶
BGP Flow Specification [RFC8955] and [RFC8956] define some BGP Network Layer Reachability Information (NLRI) formats used to distribute traffic flow specification rules. The NLRI for (AFI=1, SAFI=133) specifies IPv4 unicast filtering and the NLRI for (AFI=1, SAFI=134) specifies IPv4 BGP/MPLS VPN filtering [RFC7432]. The NLRI for (AFI=2, SAFI=133) specifies IPv6 unicast filtering and the NLRI for (AFI=2, SAFI=134) specifies IPv6 BGP/MPLS VPN filtering. The Flow Specification match part defined in [RFC8955]and[RFC8956]include L3/L4 information like IPv4/6 source/destination prefix, protocol, ports.¶
In-situ Flow Information Telemetry (IFIT) denotes a family of flow- oriented on-path telemetry techniques,which can provide high-precision flow insight and real-time network issue notification.In particular, IFIT refers to network OAM (Operations, Administration, and Maintenance) data plane on-path telemetry techniques, including In-situ OAM (IOAM) [RFC9197] and Alternate Marking [RFC9341]. It can provide flow information on the entire forwarding path on a per- packet basis in real time.¶
With the evolution of IP carried networks towards the intent-based and autonomous networks,flexible deployment of IFIT based on network dynamics and service requirements is getting a must. [I-D.draft-ietf-idr-sr-policy-ifit] defines BGP extensions to distribute SR policies carrying IFIT information so that IFIT behavior can be enabled automatically when the SR policy is applied. IFIT Attributes Sub-TLV is encoded in the Tunnel Encapsulation Attribute (23) defined in [RFC9012] using a new Tunnel-Type called SR Policy Type with codepoint 15. Once the IFIT attributes are signalled, if a packet arrives at the headend and, based on the types of steering described in [RFC9256], it may get steered into an SR Policy where IFIT methods are applied. However, in this way, IFIT is only applicable to SR policy enviroment. On the other hand, it cannot leverages the BGP FlowSpec to automatically configure traffic flow filtering to steer a packet flow into a valid SR Policy.¶
This document defines the BGP extensions to distribute BGP FlowSpec based traffic filtering together with IFIT information. So the IFIT behavior can be applied to the specified flow automatically. In this way, IFIT is automatically enabled and running.¶
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.¶
Abbreviations used in this document:¶
ACL: Access Control List¶
AFI: Address Family Identifier¶
AS: Autonomous System¶
DEX: Direct Exporting¶
IFIT: In-situ Flow Information Telemetry¶
IOAM: In situ Operation, Administration, and Maintenance¶
NLRI: Network Layer Reachability Information¶
OAM: Operation, Administration, and Maintenance¶
SAFI: Subsequent Address Family Identifier¶
IFIT attribute is an optional non-transitive BGP path attribute. IANA is requested to allocate the reserved value as the type code of the attribute in the "BGP Path Attributes" registry [IANA-BGP-PARAMS]. The attribute is composed of a set of Type-Length-Value (TLV) encodings. Each TLV contains information corresponding to a particular IFIT type. A IFIT TLV, also known as IFIT TLV, is structured as shown in Figure 1.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IFIT Type (2 octets) | Length (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Value (variable) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IFIT Type (2 octets): Identifies a type of IFIT. Two types of IFIT are defined in this document: as follows.¶
Length (2 octets): The total number of octets of the Value field.¶
Value (variable): Comprised of one or multiple sub-TLVs.¶
Each sub-TLV consists of three fields: A 1-octet type, a 1-octet length, and zero or more octets of value. A sub-TLV is structured as shown in Figure 2.¶
+--------------------------------+
| Sub-TLV Type (1 octet) |
+--------------------------------+
| Sub-TLV Length (1 octet) |
+--------------------------------+
| Sub-TLV Value (variable) |
+--------------------------------+
Sub-TLV Type (1 octet): Each sub-TLV type defines a certain OAM option about the IFIT TLV that contains this sub-TLV.¶
Sub-TLV Length (1 octet): The total number of octets of the Sub-TLV Value field.¶
Sub-TLV Value (variable): Encodings of the Value field depend on the sub-TLV type. The following subsections define the encoding in detail.¶
This section specifies a number of sub-TLVs. These sub-TLVs can be included in two TLVs of the IFIT attribute.¶
For IFIT Type 1, namely the IOAM Type, four sub-TLVs are defined in this document as follows:¶
IOAM Pre-allocated Trace Option Sub-TLV, Type=1.¶
IOAM Incremental Trace Option Sub-TLV, Type=2.¶
IOAM Directly Export (DEX) Option Sub-TLV, Type=3.¶
IOAM Edge-to-Edge Option Sub-TLV, Type=4.¶
For IFIT Type 2, namely the AltMark Type, two sub-TLVs are defined in this document as follows:¶
IOAM Sub-TLVs include four sub-TLVs, and every sub-TLV structure is defined in the following subsections.¶
The IOAM tracing data is expected to be collected at every node that a packet traverses to ensure visibility into the entire path a packet takes within an IOAM domain. The preallocated tracing option will create pre-allocated space for each node to populate its information. The structure of IOAM pre-allocated trace option sub-TLV is defined as follows:¶
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
+---------------+---------------+-------------------------------+
| Type=1 | Length=6 | Namespace ID |
+---------------+---------------+---------------+-------+-------+
| IOAM Trace Type | Flags | Rsvd |
+-----------------------------------------------+-------+-------+
Type: 1 (to be assigned by IANA).¶
Length: 6, the total number of octets of the Sub-TLV Value field.¶
Namespace ID: A 16-bit identifier of an IOAM-Namespace. The definition is described in section 4.4 of [RFC9197].¶
IOAM Trace Type: A 24-bit identifier which specifies which data types are used in the node data list. The definition is described in section 4.4 of [RFC9197].¶
Flags: A 4-bit field. The definition is described in [RFC9322] and section 4.4 of [RFC9197].¶
Rsvd: A 4-bit field reserved for further usage. It MUST be zero and ignored on receipt.¶
The incremental tracing option contains a variable node data fields where each node allocates and pushes its node data immediately following the option header. The structure of IOAM incremental trace option sub-TLV is defined as follows:¶
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
+---------------+---------------+-------------------------------+
| Type=1 | Length=6 | Namespace ID |
+---------------+---------------+---------------+-------+-------+
| IOAM Trace Type | Flags | Rsvd |
+-----------------------------------------------+-------+-------+
Type: 2 (to be assigned by IANA).¶
Length: 6, the total number of octets of the Sub-TLV Value field.¶
All the other fields definitions are the same as the pre-allocated trace option sub-TLV in section 3.1.1.¶
IOAM DEX option is used as a trigger for IOAM data to be directly exported to a collector without being pushed into in-flight data packets. The structure of IOAM DEX sub-TLV is defined as follows:¶
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
+---------------+---------------+
| Type=3 | Length=16 |
+-----------------------------------------------+---------------+
| Namespace ID | Flags |Extension-Flags|
+-------------------------------+---------------+---------------+
| IOAM Trace Type | Rsvd |
+-----------------------------------------------+---------------+
| Flow ID |
+---------------------------------------------------------------+
| Sequence Number |
+---------------------------------------------------------------+
Type: 3 (to be assigned by IANA).¶
Length: 16, the total number of octets of the Sub-TLV Value field.¶
Namespace ID: A 16-bit identifier of an IOAM-Namespace. The definition is described in section 4.4 of [RFC9197].¶
Flags: A 8-bit field. The definition is described in section 3.2 of [RFC9326].¶
Extension-Flags: A 8-bit field. The definition is described in section 3.2 of [RFC9326].¶
IOAM Trace Type: A 24-bit identifier which specifies which data types are used in the node data list. The definition is described in section 4.4 of [RFC9197].¶
Rsvd: A 4-bit field reserved for further usage. It MUST be zero and ignored on receipt.¶
Flow ID: A 32-bit flow identifier. The definition is described in section 3.2 of [RFC9326].¶
Sequence Number: A 32-bit flow identifier. The definition is described in section 3.2 of [RFC9326].¶
The IOAM edge-to-edge option is to carry data that is added by the IOAM encapsulating node and interpreted by IOAM decapsulating node. The structure of IOAM edge-to-edge option sub-TLV is defined as follows:¶
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
+---------------+---------------+
| Type=4 | Length=4 |
+-----------------------------------------------+---------------+
| Namespace ID | IOAM E2E Type |
+-------------------------------+-------------------------------+
Type: 4 (to be assigned by IANA).¶
Length: 4, the total number of octets of the Sub-TLV Value field.¶
Namespace ID: A 16-bit identifier of an IOAM-Namespace. The definition is described in section 4.4 of [RFC9197].¶
IOAM E2E Type: A 16-bit identifier which specifies which data types are used in the E2E option data. The definition is described in section 4.6 of [RFC9197].¶
AltMark Sub-TLVs include two sub-TLVs, and every sub-TLV structure is defined in the following subsections.¶
The structure of Alternate Marking sub-TLV is defined as follows:¶
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
+---------------+---------------+
| Type=1 | Length=4 |
+-------------------------------+---------------+-+-+-+-+-------+
| FlowMonID |L|D|H|E| Rsvd |
+-----------------------------------------------+-+-+-+-+-------+
Type: 1 (to be assigned by IANA).¶
Length: 4, the total number of octets of the Sub-TLV Value field.¶
FlowMonID: A 20-bit identifier to uniquely identify a monitored flow within the measurement domain. The definition is described in section 5.3 of [RFC9343].¶
L: 1-bit Loss flag for Packet Loss Measurement as described in Section 5.1 of [RFC9343].¶
D: 1-bit Delay flag for Single Packet Delay Measurement as described in Section 5.2 of [RFC9343].¶
H: 1-bit flag indicating that the measurement is Hop-by-Hop.¶
E: 1-bit flag indicating that the measurement is End-to-End.¶
Rsvd: 4-bit field reserved for further usage. It MUST be zero and ignored on receipt.¶
The structure of Enhanced Alternate Marking sub-TLV is defined as follows:¶
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
+---------------+---------------+-------+-+-+-+-+---------------+
| Type=1 | Length=4 |Period |L|D|H|E| Rsvd |
+---------------+---------------+-------+-+-+-+-+---------------+
| Flow ID |
+---------------------------------------------------------------+
| Sequence Number |
+---------------------------------------------------------------+
| Measurement Period Number |
+---------------------------------------------------------------+
Type: 2 (to be assigned by IANA).¶
Length: 14, the total number of octets of the Sub-TLV Value field.¶
Period: 4-bit field used for encoding at most 16 measuement periods.¶
L: 1-bit Loss flag for Packet Loss Measurement as described in Section 5.1 of [RFC9343].¶
D: 1-bit Delay flag for Single Packet Delay Measurement as described in Section 5.2 of [RFC9343].¶
H: 1-bit flag indicating that the measurement is Hop-by-Hop.¶
E: 1-bit flag indicating that the measurement is End-to-End.¶
Flow ID: A 32-bit identifier to uniquely identify a monitored flow within the measurement domain. The definition and usage is described in section 7 of [I-D.draft-he-ippm-ioam-dex-extensions-incorporating-am-01].¶
Sequence Number: An optional 32-bit sequence number, starting from 0 and incremented by 1 for each packet from the same flow at the encapsulating node. The Sequence Number, when combined with the Flow ID, provides a convenient approach to correlate the exported data from the same user packet.¶
Measurement Period Number(MPN): An optional 32-bit field representing the measurement period number of the monitored flow, starting from 0 and incremented by 1 for the specified flow with the same Flow ID. The field is set at the encapsulating node and exported to the receiving entity by the forwarding nodes. The MPN, when combined with the Flow ID, provides a convenient approach to correlate the exported data of the same flow during the same measurement period from multiple nodes.¶
IFIT may be applied on all the traffic flow or a subset of the traffic. For the IOAM Type, take IOAM trace monitoring as example, when an IOAM encapsulating node incorporates the IOAM Pre-allocated Trace Option type (passport mode) or the DEX Option type (postcard mode) into all packets of the user traffic it forwards, more bandwidth and processing resources are required. So it is appropriate for an IOAM encapsulating node to apply the IOAM functionality to the selected subset of the traffic. But for the AltMark Type, it is more perferable for an encapsulating node to color all the traffic of interest it forwards, not a subset of the traffic, thus the fidelity of performance measurement for user traffic flow (e.g., packet loss, delay and jitter) can be ensured.¶
This document defines a new Traffic Sampling Action standardized as BGP Extended Communities Attribute [RFC4360], which is used to carry packet sampling rate.¶
The structure of the traffic sampling Extended Community is defined as follows:¶
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
+---------------+---------------+-------------------------------+
| Type | Sub-Type | ASN |
+-------------------------------+-------------------------------+
| Sampling Rate |
+---------------------------------------------------------------+
Type: 1-octet, TBA (to be assigned by IANA).¶
Sub-Type: 1-octet, TBA (to be assigned by IANA).¶
ASN: 2-octet AS number, which can be assigned from a 2-octet AS number. When a 4-octet AS number is locally present, the 2 least significant octets of such an AS number can be used. This value is purely informational and SHOULD NOT be interpreted by the implementation.¶
Sampling Rate: 4-octet float, which carries the sampling rate information in IEEE floating point [IEEE.754.1985] format. A sampling rate of 0 should result on no packet for the particular flow to be applied to IFIT, and a sampling rate of 100% should result on all traffic for the particular flow to be be applied to IFIT. On encoding, the sampling rate MUST NOT be negative.¶
A Flow Specification is an n-tuple consisting of several matching criteria that can be applied to IP traffic flow. A given IP packet is said to match the defined Flow Specification if it matches all the specified criteria. This n-tuple is encoded into a BGP NLRI. Flow Specifications can be seen as more specific routing entries to a unicast prefix, and the routing system can take advantage of the ACL (Access Control List) capabilities in the router's forwarding path.¶
Generally, in operator network, the centralized controller determines the particular user traffic to be monitored according to service requirements; at the same time, the centralized controller also needs to determine th IFIT type applied to the specified traffic flow. Based on BGP FlowSpec, the centralized controller sends the BGP FlowSpec update message to the headend device (i.e,. IOAM encapsulating node), carrying NLRI and IFIT attributes along with the traffic sampling extended community(if present). The BGP FlowSpec update message is used to instruct the headend device to perform IFIT automatic configuration on the monitored traffic flows. The headend device automatically generates ACLs according to the received traffic filter rules, and encapsulates IFIT for the incoming specified traffic flow packets, achieving the automated configuration for the monitored traffic flows.¶
Once the centralized controller determines to terminate monitoring the specified traffic flow, it can withdraw the corresponding NRLI routes, indicating that the headend device will remove the ACLs related to the traffic filter rules and stop encapsulating IFIT for the incoming specified traffic flow packets.¶
+--------------+
| Centralized |
| Controller |
+--------------+
|
| Send BGP FlowSpec update message to Headend, carrying:
| NLRI: Traffic filter rules
| IFIT attributes
| Traffic Sampling Extended Community (may be present)
|
|
|
V (-----------------)
+-------+ ( ) +--------+
| | ( Native IP or ) | |
|Headend|-( =========================> )- |Endpoint|
+-------+ ( BGP/MPLS VPN Network ) +--------+
( )
(-----------------)
The validation procedure is the same as specified in Section 6 of [RFC8955] and Section 5 of [RFC8955].¶
Additionally, The IFIT Attribute MUST be attached to the BGP Update and MUST have a IFIT Type TLV set to the IOAM Type (1) or the AltMark Type (2).¶
When the IFIT Type TLV includes any sub-TLV that is unrecognized or unsupported, the update SHOULD NOT be considered usable. An implementation MAY provide an option for ignoring unsupported sub-TLVs.¶
A router that receives an BGP update that is not valid according to these criteria MUST treat the update as malformed.¶
The validation of the TLVs/sub-TLVs introduced in this document and defined in their respective sub-sections of Section 4 MUST be performed to determine if they are malformed or invalid. In case of any error detected, either at the attribute or its TLV/sub-TLV level, the "treat-as-withdraw" strategy MUST be applied. This is because a BGP Flowspec update without a valid IFIT Attribute (comprising of all valid TLVs/sub-TLVs) is not usable.¶
A BGP Flowspec update that is determined to be not valid, and therefore malformed, MUST be handled by the "treat-as-withdraw" strategy.¶
An implementation SHOULD log any errors found during the above validation for further analysis.¶
IANA is requested to allocate the reserved value as the type code of the attribute in the "BGP Path Attributes" registry [IANA-BGP-PARAMS].¶
Type Code Description Reference
-----------------------------------------------
TBA IFIT Attribute This document¶
IANA is requested to allocate the following values as the type code of the IFIT Attribute TLVs.¶
Value Description Reference
-----------------------------------------------
1 IOAM Type This document
2 AltMark Type This document¶
IANA is requested to allocate the following values as the type code of the IOAM Type Sub-TLVs.¶
Value Description Reference
--------------------------------------------------------------------------
1 IOAM Pre-allocated Trace Option Sub-TLV This document
2 IOAM Incremental Trace Option Sub-TLV This document
3 IOAM Directly Export (DEX) Option Sub-TLV This document
4 IOAM Edge-to-Edge Option Sub-TLV This document¶
IANA is requested to allocate the following values as the type code of the AltMark Type Sub-TLVs.¶
Value Description Reference
-------------------------------------------------------------------
1 Alternate Marking Sub-TLV This document
2 Enhanced Alternate Marking sub-TLV This document¶
IANA is requested to allocate the reserved value as the type code of Traffic Sampling Extended Community in the registry entitled "BGP Transitive Extended Community Types".¶
Type Value Sub-Type Value Description Reference -------------------------------------------------------------------------- TBA1 TBA2 Traffic Sampling This document¶
The security mechanisms of the base BGP security model apply to the extensions described in this document as well. See the Security Considerations section of [RFC4271] for a discussion of BGP security.¶
The BGP extensions specified in this document enable IFIT within an controlled domain, as defined in [RFC9378] and [I.D.draft-ietf-ippm-alt-mark-deployment]. IFIT operates within a controlled domain and its security considerations also apply to BGP sessions when carrying IFIT information. The IFIT configurations distributed by BGP are expected to be used entirely within this trusted IFIT domain which comprises a single AS or multiple ASes/ domains within a single provider network. Therefore, precaution is necessary to ensure that the IFIT information advertised via BGP sessions is limited to nodes in a secure manner within this trusted IFIT domain.¶
Flow Specification BGP speakers (e.g., the centralized controller) also need to be cautious for sending BGP updates. For example, sending updates at a high rate, or generating a high number of Flow Specifications may stress the receiving systems (the Headend devices), or exceed their capabilities.¶
Another major concern is that enabling IFIT on all the traffic flows may have some impact on network forwarding performance, thus the traffic sampling action is needed for protecting network resources. In particular, settting the appropriate traffic sampling rate for the IOAM trace monitoring is also necessary.¶