BGP Flow Specification Version 2 - for Basic IP

2.1. Flow Specification v1 (FSv1) SAFIs

The FSv1 NLRI defined in [RFC8955] and [RFC8956] include 13 match conditions encoded for the following AFI/SAFIs:¶

• IPv4 traffic: AFI:1, SAFI:133¶

• IPv6 Traffic: AFI:2, SAFI:133¶

• BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134¶

• BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134¶

Match conditions are ordered by component type in ascending order. If multiple component types filters exist, the ordering within a component type is defined by the component type. The FSv1 component format does not provide enough information to create a unique canonically sorted list for all implementations in all deployments.¶

The actions standardized for in [RFC8955] and [RFC8956] are:¶

• accept packet (default),¶

• traffic flow limitation by bytes (0x6),¶

• traffic-action (0x7),¶

• redirect traffic to VPN (0x8),¶

• mark traffic (0x9), and¶

• traffic flow rate limiting (12, 0xC)¶

An SFC action [RFC9015] defines a redirection of a data flow to an entry point into a specific SFP (Service Function Path)¶

While IDR has proposed other Extended Community Actions, no additional actions have completed the standardization process.¶

Additional proposals for FS Actions in Extended Communities exist, but these are still in the standardization process. As such, these new FS actions will fall under FSv2 rules for Extended Communities.¶

2.2. Transition to FSv2

This specification specification defines AFI/SAFI pairs to support Flow Spec for IPv4 IP IPv6, L2, IPv4 VPNs, IPv6 VPNs, L2VPN, SFC, and SFC VPN supports the components and actions for the following:¶

• IPv4 (AFI=1, SAFI=TBD1),¶

• IPv6 (AFI=2, SAFI=TBD1),¶

• L2 (AFI=6, SAFI=TDB1) [described in [I-D.ietf-idr-flowspec-l2vpn]),¶

• BGP/MPLS IPv4 VPN: (AFI=1, SAFI=TBD2),¶

• BGP/MPLS IPv6 VPN: (AFI=2, SAFI=TBD2),¶

• BGP/MPLS L2VPN (AFI=25, SAFI=TDB2) [described in [I-D.ietf-idr-flowspec-l2vpn]),¶

• SFC: (AFI=31, SAFI=TBD1),¶

• SFC VPN (AFI=31, SAFI=TBD2),¶

One question asked by developers is what AFI/SAFI is required for FSv2 IP Basic compliance. BGP negotiates support for each AFI/SAFI, so FSv2 IP Basic support for non-VPN could be as little as FSv2 for IPv4 forwarding (AFI/SAFI: 1/TBD1),¶

The IDR specification for L2 VPN traffic was specified in [I-D.ietf-idr-flowspec-l2vpn]. An IDR specification for tunneled traffic is in [I-D.ietf-idr-flowspec-nvo3]. Both of these drafts were targeted for FSv1, but the WG decided to require these to FSv2 TLV formats.¶

2.3. FSv2 Overview

FSv2 allows the user to order the flow specification rules and the actions associated with a rule. Each FSv2 rule may have one or more match conditions and one or more associated actions.¶

FSv2 operates in the ships-in-the night model with FSv1 so network operators can manipulate which the distribution of FSv2 and FSv1 using configuration parameters.¶

An FSv2 peer may receive BGP NLRI routes from a FSv1 peer or a BGP peer that does not support FSv1 or FSv2. The capabilities sent by a remote BGP peer indicate what FS supported by the AFI/SAFI (FSv1 NLRI or FSv2 NLRI or none).¶

The basic principles regarding ordering of flow specification filter rules are:¶

• 1) Rule-0 (zero) is defined to be 0/0 with the “permit-all” action.¶

• 2) FSv2 filter rules are ordered based on user-specified order.¶

  • The user-specified order is carried in the FSv2 NLRI and a numerical lower value takes precedence over a numerically higher value. For rules received with the same order value, the filter rules are ordered by FSv2 component number and then by rules specified by the component.¶

• 3) Importing FSv1 into a combined FSv2 and FSv2 rule set requires starting FSv2 with Rule 1 and adding FSv1 rules are added after FSv2 rules.¶

  • For example, BGP Peer A has FSv2 data base with 10 FSv2 rules (1-10). Suppose that, FSv1 user ordered FS are configured to start at 301 so 10 FSv1 rules are added at 301-310.¶

• 4) One or more action can be linked to a filter rule¶

  • If a single action is linked, the action either succeeds or fails.¶

  • if multiple actions are linked to a filter rule via FSv2 Extended Communities, the implementation MUST follow the FSv2-EC interaction rules in section x.x or have a local configuration knob to indicate local interaction rules. Implementations within a network SHOULD follow the same interaction rules¶

  • If an implementation allows for FSv2 actions with user-ordering and Extended Community actions, the by default the Extended Community are ordered after the user-ordered actions.¶

Figure 1 shows a diagram of the FSv2 logical data structures with 5 rules for IP Basic functionality.¶

     +--------------------------------------+
     | Flow Specification (FS)              |
     |  Policy                              |
     +--------------------------------------+
         ^               ^              ^
         |               |              |
         |               |              |
+--------^----+  +-------^-------+     +-------------+
|   FS Rule 1 |  |   FS Rule 2   | ... |  FS rule 5  |
+-------------+  +---------------+     +-------------+
                      :  :  :  :
    :.................:  :  :  :
    :       :............:  :  :
 +--V--+ +--V-------+       :  :
 |order| |Dependent | ......:  :..
 |     | | filter   | :          :
 +-----+ | chain    | :          :
         +----------+ :          :
                      :          :
                      :          :
                 .....:          :........
                 :                     :
       +---------V-----------+    +----V-------------+
       |  Rule Condition     |    |   Rule Action    |
       |  in BGP NLRIs       |    | in BGP extended  |
       | AFI/SAFI 1/133,     |    | Communities      |
       | 1/134, 2/133, 2/134 |    |                  |
       +-------------------+      +------------------+
           :     :    :                 :      :    :
      .....:     .    :.....       .....:      .    :.....
      :          :         :       :           :         :
 +----V---+  +---V----+ +--V---+ +-V------+ +--V-----++--V---+
 |  Match |  | match  | |match | | Action | | action ||action|
 |Operator|  |Variable| |Value | |Operator| |variable|| Value|
 |*1      |  |        | |      | |(subtype| |        ||      |
 +--------+  +--------+ +------+ +--------+ +--------++------+

   *1 match operator may be complex.

   Figure 2-1: BGP Flow Specification v1 Policy

3.1. FSv2 NLRI Format

The BGP FSv2 supports NRLI with the format for AFIs for IPv4 (AFI = 1), IPv6 (AFI = 2), L2 (AFI = 6), L2VPN (AFI=25), and SFC (AFI=31) with SAFIs TBD1 (Flow Spec) and TBD2 (Flow Spec for VPNs) to support transmission of the flow specification which supports user ordering of traffic filters and actions for IP traffic and IP VPN traffic.¶

A compliant FSv2 implementation only has to implement one AFI/SAFI pair out of the full list of NRLIs. For example, a compliant FSv2 implementation could only implement IPv4 FSv2 (AFI=1, SAFI=TBD1).¶

This NLRI information is encoded using MP_REACH_NLRI and MP_UNREACH_NLRI attributes defined in [RFC4760]. When advertising FSv2 NLRI, the length of the Next-Hop Network Address MUST be set to 0. Upon reception, the Network Address in the Next-Hop field MUST be ignored.¶

Implementations wishing to exchange flow specification rules MUST use BGP's Capability Advertisement facility to exchange the Multiprotocol Extension Capability Code (Code 1) as defined in [RFC4760], and indicate a capability for FSv1, FSv2 (Code TBD3), or both.¶

The AFI/SAFI NLRI for BGP Flow Specification version 2 (FSv2) has the format:¶

 +--------------------------------+
 | NLRI length (2 octets)         |
 +--------------------------------+
 | TLVs+                          |
 +--------------------------------+

  Figure 3-1 - NLRI format

where:¶

• NLRI length: length of field including all SubTLVs in octets.¶

• TLV+ - indicates the repetition of the TLV field¶

Each each TLV has the Format:¶

     TLV format
 +--------------------------------+
 | +============================+ |
 | | order (4 octets)           | |
 | +----------------------------+ |
 | | Dependent filters chain    | |
 | |(type, chain ID, count,     | |
 | | item) (8 octets)           | |
 | +----------------------------+ |
 | + FSv2 Filter type (2 octet) + |
 | +----------------------------+ |
 | + length TLVs (2 octet)      + |
 | + ---------------------------+ |
 | + value (variable)           + |
 | +----------------------------+ |
 +-------------------------------+

 Figure 3-2 - TLV format within FSv2 NLRI

where:¶

• order: flow-specification global rule order number (4 octets).¶

• Dependent Filters Chain: 8 octets for identifying a chain of FSv2 filters that must be deployed at the same time.¶

  Why needed in FSv2:

  Flow specification filters distributed in BGP UPDATE packets may be broken into multiple packets. In FSv2, the dependent filter ID allows the filter chains to be identified across all user-defined or default filters. The rules can be installed from BGP into the firewall after all filters have been installed.¶

  For basic FSV2:

  This field is required to be set to all zero, and ignored upon reception.¶

  For future FSV2:

  Future specifications will specify the use of this field, and future specifications will continue to ignore the field if the value is all zeros.¶

• FSv2 Filter type: contains a type for FSv2 TLV format of the NRLI (2 octets). This type specifies support for a set of components. [Editor's note: We need to decide between Option 2 or Option 1. Option 2 makes provides a better default ordering for frame/packet filters.¶

  Option 1

  ascending order (draft-ietf-idr-fsv2-ip-basic-02)¶

  0 - reserved,¶

  1 - IP Basic Filter rules¶

  2 - IP Extended Filter Rules¶

  3 - MPLS Filter Rules¶

  4 - L2 traffic rules¶

  5 - SFC Traffic rules¶

  6 - Tunneled traffic¶

  Option 2

  ordering by frame/packet (new)¶

  0 - reserved,¶

  50 - L2 Traffic fules¶

  100 - MPLS traffic rules¶

  150 - SFC Traffic rules¶

  200 - Tunneled traffic¶

  256 - IP Basic Filter Rules (bit 1 of high bit)¶

  280 - IP Extended Filter Rules¶

• length-TLV: is the length of the value part of the Sub-TLV,¶

• value: value depends on the type of FSv2 Filter type.¶

FSv2 implementations MUST pass valid filter TLVs even if the implementation does not support these installation of these a particular type of filter rules.¶

This specification only defines operation of the IP Basic Filter Rules that all FSv2 must support.¶

3.2. FSv2 Basic IP Filters

    0   1   2   3   4   5   6   7
  +---+---+---+---+---+---+---+---+
  | e | a |  len  | 0 |lt |gt |eq |
  +---+---+---+---+---+---+---+---+

        Figure 3-3: Numeric Operator (numeric_op)

            +====+====+====+==================================+
            | lt | gt | eq | Resulting operation              |
            +====+====+====+==================================+
            | 0  | 0  | 0  | false (independent of the value) |
            +----+----+----+----------------------------------+
            | 0  | 0  | 1  | == (equal)                       |
            +----+----+----+----------------------------------+
            | 0  | 1  | 0  | > (greater than)                 |
            +----+----+----+----------------------------------+
            | 0  | 1  | 1  | <= (greater than or equal)       |
            +----+----+----+----------------------------------+
            | 1  | 0  | 0  | < (less than)                    |
            +----+----+----+----------------------------------+
            | 1  | 0  | 1  | <= (less than or equal)          |
            +----+----+----+----------------------------------+
            | 1  | 1  | 0  | != (not equal value)             |
            +----+----+----+----------------------------------+
            | 1  | 1  | 1  | true (independent of the value)  |
            +----+----+----+----------------------------------+

               Table 3-1: Comparison Operation Combinations

     0   1   2   3   4   5   6   7
    +---+---+---+---+---+---+---+---+
    | e | a |  len  | 0 | 0 |not| m |
    +---+---+---+---+---+---+---+---+

    Figure 3-4 Bitmask Operator (bitmask_op)

   Top-level TLV
 +-------------------------------+
 | +============================+ |
 | | order (4 octets)           | |
 | +----------------------------+ |
 | | dependency filter chain    | |
 | |  (8 octets)                | |
 | +----------------------------+ |
 | + FSv2 Filter type (2 octets)| |
 | | option1: 1, option2: 256   | |
 | +----------------------------+ |
 | + length (2 octet)           + |
 | + ---------------------------+ |
 | + value (variable)           + |
 | +----------------------------+ |
 +--------------------------------+

Figure 3-5 NLRI format for FSv2 IP Filter Type

Table 3-2 FSv2 IP Basic TLV Components

Sub-TLV   Definition
--------  ---------------------
   0 -    Reserved
   1 -    IP Destination prefix
   2 -    IP Source prefix
   3 –    IPv4 Protocol /
          IPv6 Upper Layer Protocol
   4 –    Port
   5 –    Destination Port
   6 –    Source Port
   7 –    ICMPv4 type / ICMPv6 type
   8 –    ICMPv4 code / ICPv6 code
   9 –    TCP Flags
  10 –    Packet length
  11 –    DSCP
  12 –    Fragment
  13 –    Flow Label
  14-255  Reserved

      0    1   2   3   4   5   6  7
    +---+---+---+---+---+---+---+---+
    | 0 | 0 | 0 | 0 |LF |FF |IsF| DF|
    +---+---+---+---+---+---+---+---+
                 Figure 3-8

3.3. FSv2 Actions for FSv2 IP Basic

The IP Basic FSv2 allows FS actions to be sent in an Extended Community (FSv2-EC) for IPv4 and IPv6. The Extended Community encodes the Flow Specification actions in the Extended IPv4 Community format [RFC4360] or in the extended IPv6 Community format [RFC5701].¶

A Flow Spec filter match maybe linked to only one Flow Spec action. For these deplyments, the details on multiple actions per flow spec filter match in this section can be ignored.¶

When an operator defines multiple Flow Spec Extended Community (FS-EC) Actions for single filter match, it is possible that some FS-EC actions can interact If one sorts the FS-EC actions into categories, the interactions can be minimized. One example of such interactions is if the flow is redirect to a VRF and to a VPN. Another way two actions interact is if an action fails. For example, if set DSCP action fails prior to redirect to a VPN may have undesired data flow patterns.¶

This section defines the FS-EC actions, categories of FS-EC actions, and ways to minimize interactions between FS-EC actions. Section 3.3.1 describes the existing FS-EC action formats. Section 3.3.2 describes the interaction between FS-EC action, and categories of actions, and the way to minimizes interactions. Should the BGP to distribute information about the configured interactions for sequences of multiple actions, Section 3.3 defines an optional FS-EC to pass information ordering of categories (user/this standard) and failure action (stop or best effort).¶

Note that FSv2 implementations that only associate 1 FSv2-EC per filter match do not need the FSv2-EC.¶

  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 high    |  Type low(*)  |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value (6 octets)     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 3-9

               Table 3-3
  FSv1 Transitive Extended Communities for IP Basic
      High-Low byte of Transitive FS-EC

H-L      FSv1 Description               Short-ID FS document
======   ==================             ======== ==========
0x01-0C  Transitive IPv4                RDIPv4   RDIP
0x07-02  FSv1 for an Interface set      TAIS     ifset
0x09-xx  Redirect to Indirection ID     RGID     RGID
0x0b-00  SFC Reserved                   SFC-R    RFC9015
0x0b-01  SFVC SFIR POOL Identifier      SFIR-PI  RFC9015
0x0b-02  SFC MPLS label stack Swapping  SFC-MPLS RFC9015
         or stacking labels
0x80-06  Traffic rate limit by bytes    TRB      RFC8955
0x80-07  Traffic Action                 TA       RFC8955
         (sample, terminal)
0x80-08  Redirection to VRF (2 AS form) RDIP     RFC8955
0x80-09  Traffic mark DSCP              TM       RFC8955
0x80-0C  Traffic rate limit by packets  TRP      RFC8955
0x81-08  Redirect to VPN (IPv4 form)    RDIP     RFC8955
0x81-08  Redirect to VPN (4 AS form)    RDIP     RFC8955

  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 (high)   |  Sub-type     |   Global Administrator        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |         Global Administrator (cont.)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Global Administrator (cont.)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Global Administrator (cont.)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Global Administrator (cont.)  |   Local Administrator         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3-10

The 20 octets of value are given in the following format:
Global Administrator: IPv6 address assigned by Internet Registry
Local Administrator:  2 bytes of Local Administrator

                  Table 3-4
Transitive IPv6-Address-Specific Extended Community Types

H-L byte  FSv1 Description        Short-ID FS document
======    ==================      ======== ==========
0x0000    Unassigned
0x0001    Unassigned
0x0002    Route Target            RT        No
0x0003    Route origin            ROrg      No (deprecated)
0x0004    OSPFv3 Route Attribute  OSPFv3    No (deprecated)
0x0005    FIT Tail Community      IFITv6    No
0x0006    Link Bandwidth          LBW       No
0x0008    Unassigned
0x0009    Unassigned
0x000A    Unassigned
0x000B    VRF Route Import        VRP-I     No
0x000C    FS Redirect to IPv6     RDIPv6C   Yes: RDIP
0x000D    FS Redirect to IPv6     RDIPv6    Yes: RFC8956
0x000E    Unassigned
Ox000F    Unassigned
0x0010    Cisco VPN distinguisher Cisco-VPN  No
0x0011    UUID-based Route Target UUID-RT    No
0x0012    Inter-ARea P2MP S-NH    PM2P-NH    No
0x0013    Unassigned
0x0014    VRF Recursive NH        VRF-RNH    no
0x0015    RT-derived-EC           RT-EC      no

 Generic Transitive Extended Community (IPv4)

   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 high    |  Type low     |AC-interaction |  AC-Failure   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Reserved  (4 octets)                                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3-11

4.1. Validation of FSv2 NLRI

The validation of FSv2 NLRI adheres to the combination of rules for general BGP FSv1 NLRI found in [RFC8955], [RFC8956], [RFC9117]. These FSv1 rules are sufficient for FSv2 for IP traffic.¶

Specific additions have been defined for IP Filters used for guiding IP traffic into Service Function Service Function Pathways SFC NLRI in [RFC9015], or validation of L2VPN FS NLRI (see [I-D.ietf-idr-flowspec-l2vpn]). These additions are not required for the FSv2 for IP Basic functions. Therefore, FSv2 NLRI validation for Basic IP uses the same rules as FSv1.¶

To provide clarity, the full validation process for flow specification routes (FSv1 or FSv2) for all AFI/SAFIs is described below in section x.x rather than simply referring to the relevant portions of these RFCs. Validation only occurs after BGP UPDATE message reception and the FSv2 NLRI and the path attributes relating to FSv2 (Extended community and Wide Community) have been determined to be well-formed. Any MALFORMED FSv2 NRLI is handled as a “session reset” [RFC7606].¶

4.2. Ordering of FS filters for BGP Peers which support FSv1 and FSv2

FSv2 allows the user to order flow specification rules and the actions associated with a rule. Each FSv2 rule has one or more match conditions and one or more actions associated with each rule.¶

FSv1 and FSv2 filters are sent as different AFI/SAFI pairs so FSv1 and FSv2 operate as ships-in-the-night. Some BGP peers in an AS may support both FSv1 and FSv2. Other BGP peers may support FSv1 or FSv2. Some BGP will not support FSv1 or FSV2. A coherent flow specification technology must have consistent best practices for ordering the FSv1 and FSv2 filter rules.¶

One simple rule captures the best practice: Order the FSv1 filters after the FSv2 filter by placing the FSv1 filters after the FSv2 filters.¶

To operationally make this work, all flow specification filters should be included the same data base with the FSv1 filters being assigned a user- defined order beyond the normal size of FSv2 user-ordered values. A few examples, may help to illustrate this best practice.¶

Example 1: User ordered numbering - Suppose you might have 1,000 rules for the FSv2 filters. Assign all the FSv1 user defined rules to 1,001 (or better yet 2,000). The FSv1 rules will be ordered by the components and component values.¶

Example 2: Storage of actions - All FSv1 actions are defined ordered actions in FSv2. Translate your FSv1 actions into FSv2 ordered actions for storing in a common FSv1-FSv2 flow specification data base.¶

6.1. BGP FSv2 with ROA

BGP FSv2 can utilize ROAs in the validation. If BGP FSv2 is used with BGPSEC and ROA, the first thing is to validate the route within BGPSEC and second to utilize BGP ROA to validate the route origin.¶

The BGP-FS peers using both ROA and BGP-FS validation determine that a BGP Flow specification is valid if and only if one of the following cases:¶

• If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in destination address match filter and the following is true:¶

  • A BGP ROA has been received to validate the originator, and¶

  • The route is the best-match unicast route for the destination prefix embedded in the match filter; or¶

• If a BGP ROA has not been received that matches the IPv4 or IPv6 destination address in the destination filter, the match filter must abide by the [RFC8955] and [RFC8956] validation rules as follows:¶

  • The originator match of the flow specification matches the originator of the best-match unicast route for the destination prefix filter embedded in the flow specification", and¶

  • No more specific unicast routes exist when compared with the flow destination prefix that have been received from a different neighboring AS than the best-match unicast route, which has been determined in step A.¶

The best match is defined to be the longest-match NLRI with the highest preference.¶

9.1. Normative References

[I-D.ietf-idr-flowspec-interfaceset]

Litkowski, S., Simpson, A., Patel, K., and J. Haas, "Applying BGP flowspec rules on a specific interface-set", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-interfaceset-06, 2 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-interfaceset-06>.

[I-D.ietf-idr-flowspec-l2vpn]

Hao, W., 3rd, D. E. E., Litkowski, S., and S. Zhuang, "BGP Dissemination of L2 Flow Specification Rules", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-l2vpn-27, 16 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-27>.

[I-D.ietf-idr-flowspec-nvo3]

Eastlake, D. E., Weiguo, H., Zhuang, S., Li, Z., and R. Gu, "BGP Dissemination of Flow Specification Rules for Tunneled Traffic", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-nvo3-23, 5 December 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-23>.

[I-D.ietf-idr-flowspec-path-redirect]

Van de Velde, G., Patel, K., and Z. Li, "Flowspec Indirection-id Redirect", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-path-redirect-12, 24 November 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect-12>.

[I-D.ietf-idr-flowspec-redirect-ip]

Haas, J., Henderickx, W., and A. Simpson, "BGP Flow-Spec Redirect-to-IP Action", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-06, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-06>.

[I-D.ietf-idr-flowspec-srv6]

Li, Z., Chen, H., Loibl, C., Mishra, G. S., Fan, Y., Zhu, Y., Liu, L., Liu, X., and S. Zhuang, "BGP Flow Specification for SRv6", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-srv6-08, 24 November 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-srv6-08>.

[I-D.ietf-idr-wide-bgp-communities]

Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., and P. Jakma, "BGP Community Container Attribute", Work in Progress, Internet-Draft, draft-ietf-idr-wide-bgp-communities-12, 17 March 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-wide-bgp-communities-12>.

[RFC0791]

Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[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, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4360]

Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, <https://www.rfc-editor.org/info/rfc4360>.

[RFC4456]

Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/info/rfc4456>.

[RFC4760]

Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC5065]

Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.

[RFC5701]

Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009, <https://www.rfc-editor.org/info/rfc5701>.

[RFC7153]

Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <https://www.rfc-editor.org/info/rfc7153>.

[RFC7606]

Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[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, <https://www.rfc-editor.org/info/rfc8955>.

[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, <https://www.rfc-editor.org/info/rfc8956>.

[RFC9015]

Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. Jalil, "BGP Control Plane for the Network Service Header in Service Function Chaining", RFC 9015, DOI 10.17487/RFC9015, June 2021, <https://www.rfc-editor.org/info/rfc9015>.

[RFC9117]

Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. Mohapatra, "Revised Validation Procedure for BGP Flow Specifications", RFC 9117, DOI 10.17487/RFC9117, August 2021, <https://www.rfc-editor.org/info/rfc9117>.

[RFC9184]

Loibl, C., "BGP Extended Community Registries Update", RFC 9184, DOI 10.17487/RFC9184, January 2022, <https://www.rfc-editor.org/info/rfc9184>.

[RFC9582]

Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, <https://www.rfc-editor.org/info/rfc9582>.

9.2. Informative References

[I-D.hares-idr-fsv2-more-ip-actions]

Hares, S., "BGP Flow Specification Version 2 - More IP Actions", Work in Progress, Internet-Draft, draft-hares-idr-fsv2-more-ip-actions-03, 17 October 2024, <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-more-ip-actions-03>.

[I-D.hares-idr-fsv2-more-ip-filters]

Hares, S., "BGP Flow Specification Version 2 - More IP Filters", Work in Progress, Internet-Draft, draft-hares-idr-fsv2-more-ip-filters-04, 15 November 2024, <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-more-ip-filters-04>.

[I-D.ietf-idr-flowspec-v2]

Hares, S., Eastlake, D. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-v2-04, 28 April 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-04>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8205]

Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>.

[RFC8206]

George, W. and S. Murphy, "BGPsec Considerations for Autonomous System (AS) Migration", RFC 8206, DOI 10.17487/RFC8206, September 2017, <https://www.rfc-editor.org/info/rfc8206>.