BGP Flow Specification Version 2 - for Basic IP
Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline
MI
48176
USA
+1-734-604-0332
shares@ndzh.com
Donald Eastlake
Independent
2386 Panoramic Circle
Apopka
FL
32703
USA
+1-508-333-2270
d3e3e3@gmail.com
Jie Dong
Huawei Technologies
No. 156 Beiqing Road
Beijing
China
jie.dong@huawei.com
Chaitanya Yadlapalli
ATT
USA
cy098d@att.com
Sven Maduschke
Verizon
DE
sven.maduschke@de.verizon.com
2024
Routing Area
IDR Working Group
RFC
Request for Comments
I-D
Internet-Draft
BGP FSv2 - IP Basic
BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 8956, and RFC 9117 describes the distribution of traffic filter policy (traffic filters and actions) distributed via BGP. During the deployment of BGP FSv1 a number of issues were detected, so version 2 of the BGP flow specification (FSv2) protocol addresses these features. In order to provide a clear demarcation between FSv1 and FSv2, a different NLRI encapsulates FSv2.
The IDR WG requires two implementation. Implementers feedback on FSv2 was that FSv2 has a correct design, but that breaking FSv2 into a progression of documents would aid deployment of the draft (basic, adding more filters, and adding more actions). This document specifies the basic FSv2 NLRI with user ordering of filters added to FSv1 IP Filters and FSv2 actions.

Introduction
Version 2 of BGP flow specification was original defined in [I-D.ietf-idr-flowspec-v2] (BGP FSv2).
FSv2 is an update to BGP Flow specification version 1 (BGP FSv1). BGP FSv1 as defined in [RFC8955], [RFC8956], and [RFC9117] specified 2 SAFIs (133, 134) to be used with IPv4 AFI (AFI = 1) and IPv6 AFI (AFI=2).
The BGP FSv2 specification was consider technically correct, but it contains more than the initial implementers desired. Why? The IDR WG requires two implementations of any specification. The BGP FSv2 draft will remain a WG draft, but the content will be split out into a series of drafts (basic, adding more IP filters, adding more IP actions, and individual functions for TTL, MPLS and SRv6).
This draft (FSv2 Basic) provides the basic FSv2 framework specification for transmitting user-ordered IP filters in the FSV2 NLRI with Extended Ccommunity to specify actions.
This document specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended).
FSv1 and FSv2 use different AFI/SAFIs to send flow specification filters. Since BGP route selection is performed per AFI/SAFI, this approach can be termed “ships in the night” based on AFI/SAFI.
The remainder of section 1 provides background on why the FSv2 was necessary to fix problems with FSv1. Section 2 contains a Primer on FSv1 (section 2.1) and FSv2 (section 2.2). Section 3 contains the encoding rules for FSv2 and user-based encoding sent via BGP. Section 4 describes how to validate and order FSv2 NLRI. Sections 5-8 discusses scalability, optional security additions, security considerations, and IANA considerations.

Why Flow Specification v2
Modern IP routers have the capability to forward traffic and to classify, shape, rate limit, filter, or redirect packets based on administratively defined policies. These traffic policy mechanisms allow the operator to define match rules that operate on multiple fields within header of an IP data packet. The traffic policy allows actions to be taken upon a match to be associated with each match rule. These rules can be more widely defined as “event-condition-action” (ECA) rules where the event is always the reception of a packet.
BGP ([RFC4271]) flow specification as defined by [RFC8955], [RFC8956], [RFC9117] specifies the distribution of traffic filter policy (traffic filters and actions) via BGP to a mesh of BGP peers (IBGP and EBGP peers). The traffic filter policy is applied when packets are received on a router with the flow specification function turned on. The flow specification protocol defined in [RFC8955], [RFC8956], and [RFC9117] will be called BGP flow specification version 1 (BGP FSv1) in this draft.
Some modern IP routers also include the abilities of firewalls which can match on a sequence of packet events based on administrative policy. These firewall capabilities allow for user ordering of match rules and user ordering of actions per match.
Multiple deployed applications currently use BGP FSv1 to distribute traffic filter policy. These applications include: 1) mitigation of Denial of Service (DoS), 2) traffic filtering in BGP/MPLS VPNS, and 3) centralized traffic control for networks utilizing SDN control of router firewall functions, 4) classifiers for insertion in an SFC, and 5) filters for SRv6 (segment routing v6).
During the deployment of BGP flow specification v1, the following issues were detected:
- lack of consistent TLV encoding prevented extension of encodings,
- inability to allow user defined order for filtering rules,
- inability to order actions to provide deterministic interactions or to allow users to define order for actions, and
- no clearly defined mechanisms for BGP peers which do not support flow specification v1.
Networks currently cope with some of these issues by limiting the type of traffic filter policy sent in BGP. Current Networks do not have a good workaround/solution for applications that receive but do not understand FSv1 policies.
FSv1 is a critical component of deployed applications. Therefore, this specification defines how FSv2 will interact with BGP peers that support either FSv2, FSv1, FSv2 and FSv1,or neither of them. It is expected that a transition to FSv2 will occur over time as new applications require FSv2 extensibility and user-defined ordering for rules and actions or network operators tire of the restrictions of FSv1 such as error handling issues and restricted topologies.

Definitions and Acronyms
AFI -
Address Family Identifier
AS -
Autonomous System
BGPSEC -
secure BGP [RFC8205] updated by [RFC8206]
BGP Session ephemeral state -
state which does not survive the loss of BGP peer session.
BGP Commmunity Path Attribute -
BGP Path attribute for Community defined by [I-D.hares-idr-bgp-community-attribute]
Configuration state -
state which persist across a reboot of software module within a routing system or a reboot of a hardware routing device.
CPA -
BGP Community Path Attribute
DDOs -
Distributed Denial of Service.
Ephemeral state -
state which does not survive the reboot of a software module, or a hardware reboot. Ephemeral state can be ephemeral configuration state or operational state.
FSv1 -
Flow Specification version 1 [RFC8955] [RFC8956]
FSv2 -
Flow Specification version 2 (this document)
FS -
Flow Specification (either v1 or v2)
FS-EC -
FS related Extended Community with FS actions
FSv1-EC -
FSv1 related Extended Community with FS Actions supported by FSv1
FSv2-EC -
FSv2 related Extended Community with FS Actions supported by FSv2
NETCONF -
The Network Configuration Protocol [RFC6241].
RESTCONF -
The RESTCONF configurati on Protocol [RFC8040]
RIB -
Routing Information Base.
ROA -
Route Origin Authentication [RFC9582]
RR -
Route Reflector.
SAFI –
Subsequent Address Family Identifier

RFC 2119 language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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.

Flow Specification Version 2 Primer
A BGP Flow Specification (v1 or v2) is an n-tuple containing one or more match criteria that can be applied to IP traffic, traffic encapsulated in IP traffic or traffic associated with IP traffic. The following are examples of such traffic: IP packet or an IP packet inside a L2 packet (Ethernet), an MPLS packet, and SFC flow.
A given Flow Specification NLRI may be associated with a set of path attributes depending on the particular application, and attributes within that set may or may not include reachability information (e.g., NEXT_HOP). FSv1 and FSv2-DDOS use only the Extended Community to encode a set of pre-determined actions. The full FSv2 uses either Extended Communities or Wide Communities to encode actions.
A particular application is identified by a specific AFI/SAFI (Address Family Identifier/Subsequent Address Family Identifier) and corresponds to a distinct set of RIBs. Those RIBs should be treated independently of each other in order to assure noninterference between distinct applications.
BGP processing treats the NLRI as a key to entries in AFI/SAFI BGP databases. Entries that are placed in the Loc-RIB are then associated with a given set of semantics which are application dependent. Standard BGP mechanisms such as update filtering by NLRI or by attributes such as AS_PATH or large communities apply to the BGP Flow Specification defined NLRI-types.
Network operators can control the propagation of BGP routes by enabling or disabling the exchange of routes for a particular AFI/SAFI pair on a particular peering session. As such, the Flow Specification may be distributed to only a portion of the BGP infrastructure.

Flow Specification v1 (FSv1) Overview
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
If one considers the reception of the packet as an event, then BGP FSv1 describes a set of Event-MatchCondition-Action (ECA) policies where:
event is the reception of a packet,
condition stands for “match conditions” defined in the BGP NLRI as an n-tuple of component filters, and
the action is either: the default condition (accept traffic), or a set of actions (1 or more) defined in Extended BGP Community values [RFC4360].
The flow specification conditions and actions combine to make up FSv1 specification rules. Each FSv1 NLRI must have a type 1 component (destination prefix). Extended Communities with FSv1 actions can be attached to a single NLRI or multiple NLRIs in a BGP message
Within an AFI/SAFI pair, FSv1 rules are ordered based on the components in the packet (types 1-13) ordered from left-most to right-most and within the component types by value of the component. Rules are inserted in the rule list by component-based order where an FSv1 rule with existing component type has higher precedence than one missing a specific component type,
Since FSv1 specifications ([RFC8955], [RFC8956], and [RFC9117]) specify that the FSv1 NLRI MUST have a destination prefix (as component type 1) embedded in the flow specification, the FSv1 rules with destination components are ordered by IP Prefix comparison rules for IPv4 ([RFC8955]) and IPv6 ([RFC8956]). [RFC8955] specifies that more specific prefixes (aka longest match) have higher precedence than that of less specific prefixes and that for prefixes of the same length the lower IP number is selected (lowest IP value). [RFC8955] specifies that if the offsets within component 1 are the same, then the longest match and lowest IP comparison rules from [RFC8955] apply. If the offsets are different, then the lower offset has precedence.
These rules provide a set of FSv1 rules ordered by IP Destination Prefix by longest match and lowest IP address. [RFC8955] also states that the requirement for a destination prefix component “MAY be relaxed by explicit configuration” Since the rule insertions are based on comparing component types between two rules in order, this means the rules without destination prefixes are inserted after all rules which contain destination prefix component.
The actions specified in FSv1 are:
- accept packet (default),
- traffic flow limitation by bytes (0x6),
- traffic-action (0x7),
- redirect traffic (0x8),
- mark traffic (0x9), and
- traffic flow limitation by packets (12, 0xC)
Figure 1 shows a diagram of the FSv1 logical data structures with 5 rules. If FSv1 rules have destination prefix components (type=1) and FSv1 rule 5 does not have a destination prefix, then FSv1 rule 5 will be inserted in the policy after rules 1-4.

     +--------------------------------------+
     | Flow Specification (FS)              |
     |  Policy                              |
     +--------------------------------------+
       	 ^               ^              ^
         |               |              |
         |               |              |
+--------^----+  +-------^-------+     +-------------+
|   FS Rule 1 |  |   FS Rule 2   | ... |  FS rule 5  |
+-------------+  +---------------+     +-------------+
                    :          :
                    :          :
                 ...:          :........
                 :                     :
       +---------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

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. The IDR WG draft [I-D.ietf-idr-flowspec-v2] contains the complete solution for FSv2. However, this complete solution makes implementation of these features a large task so, please see the next section on how the complete solution is broken into a series of solutions. This section describres the complete solution.
The original FSv2 specification [I-D.ietf-idr-flowspec-v2] 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),
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 implement these as FSv2. The series of FSv2 support the same scope of functionality in a series of documents.
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. Since the lack of deterministic ordering was an FSv1 problem, this specification provides rules and protocol features to keep filters in a deterministic order between FSv1 and FSv2.
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 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 FSv1 rules apply (order by component type and then by value of the components).
3) FSv2 rules are added starting with Rule 1 and FSv1 rules are added after FSv2 rules
  For example, BGP Peer A has FSv2 data base with 10 FSv2 rules (1-10). FSv1 user number is configured to start at 301 so 10 FSv1 rules are added at 301-310.
4) 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 BGP peer indicate whether the AFI/SAFI can be received (FSv1 NLRI or FSv2 NLRI).
5) Associate a chain of actions to rules based on user-defined action number (1-n). (optional)
  If no actions are associated with a filter rule, the default is to drop traffic the filter rules match
  An action chain of 1-n actions can be associated with a set of filter rules can via Extended Communities or a Community Path attribute with a FSv2 type. Only the Community attribute allows for user-defined order for the actions. 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. This FSv2 action order default can be changed by the Action Chain Ordering FSv2 action. Currently, there is no FSv2 definition for an action dependency chain, but space has been left in the BGP Community Path attribute format for development of action dependency mechanisms.
Figure 2-2 provides a logical diagram of the FSv2 structure

       +--------------------------------+
       |          Rule Group            |
       +--------------------------------+
         ^          ^                  ^
         |          |---------         |
         |                   |         ------
         |                   |               |
+--------^-------+   +-------^-----+     +---^-----+
|      Rule1     |   |     Rule2   | ... |  Rule-n |
+----------------+   +-------------+     +---------+
                      :  :   :    :
    :.................:  :   :    :
    :	    :............:   :    :
 +--V--+ +--V-------+        :    :
 |order| |Dependent | .......:    :
 |     | | filter   | :
 +-----+ | chain    | :
         +----------+ :           :
                      :           :
   +------------------V--+  +-----V----------------+
   |Rule Match condition |  | Rule Action          |
   +---------------------+  +----------------------+
      :     :    :           :    :     :   :    :
      :     :    :    +------V-+  :     :   :    :
      :     :    :    | action |  :     :   :    :
      :     :    :    | order  |  :     :   :    :
      :     :    :    +--------+  :     :   :    :
      :     :    :     +----------V-+   :   :    :
      :     :    :     | action     |   :   :    :
      :     :    :     | Dependency |   :   :    :
      :     :    :     | chain      |   :   :    :
      :     :    :     +------------+	:   :    :.........
      :     :    :..........            :   :             :
      :     ......         :       .....:   :...          :
      :          :         :       :           :          :
 +----V---+  +--V-----+ +--V---+ +-V------+ +--V-----+ +--V---+
 |  Match |  | match  | |match | | Action | | action | |action|
 |Operator|  |variable| |Value | |Operator| |Variable| | Value|
 +--------+  +--------+ +------+ +--------+ +--------+ +------+

   Figure 2-2: BGP FSv2 Data storage

FSv2 NLRI Formats and Actions

FSv2 NLRI Format
The BGP FSv2 uses an 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 and TBD2 to support transmission of the flow specification which supports user ordering of traffic filters and actions for IP traffic and IP VPN traffic.
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 spedcification 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) which can be:
  - 0 - reserved,
  - 1 - IP Basic Filter Rules
  - 2 - Extended IP Filter rules
  - 3 - MPLS Traffic Rules
  - 4 - L2 traffic rules
  - 5- SFC Traffic rules
  - 6 - Tunneled traffic
- length-TLV: is the length of the value part of the Sub-TLV,
- value: value depends on the type of FSv2 Filter type.
All FSv2 function must recognize valid Filter Types, even if the handling of the Filter types are not supported by the implementation. The TLV allows all FSv2 Filter types to be passed, even if the Filter rules cannot be installed.
This specification only defines operation of the IP Basic Filter Rules that all FSv2 must support.

Ordering of TLVs within the FSv2 NLRI
For ease of processing, the ordering within the FSV2 NLRI SHOULD be by order number. Within an order value (e.g. 20), it MAY be helpful to group the filters by the same filter type (e.g. 1 for IP Basic). The order within a filter type (e.g. IP Basic Filters) is defined within a filter type.

FSv2 Basic IP Filters

Operators for comparison

Numeric Operator (numeric_op)
This operator is encoded as shown in Figure 3-3.

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

        Figure 3-3: Numeric Operator (numeric_op)

e (end-of-list bit):
Set in the last {op, value} pair in the list
a (AND bit):
If unset, the result of the previous {op, value} pair is logically ORed with the current one. If set, the operation is a logical AND. In the first operator octet of a sequence, it MUST be encoded as unset and MUST be treated as always unset on decoding. The AND operator has higher priority than OR for the purposes of evaluating logical expressions.
len (length):
The length of the value field for this operator given as (1 << len). This encodes 1 (len=00), 2 (len=01), 4 (len=10), and 8 (len=11) octets.
0
MUST be set to 0 on NLRI encoding and MUST be ignored during decoding
lt
less-than comparison between data and value
gt:
greater-than comparison between data and value
eq:
equality between data and value
The bits lt, gt, and eq can be combined to produce common relational operators, such as "less or equal", "greater or equal", and "not equal to", as shown in Table 3-1.

            +====+====+====+==================================+
            | 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

Bitmask Operator (bitmask_op)
This operator is encoded as shown in Figure 3-4.

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

    Figure 3-4 Bitmask Operator (bitmask_op)

Where:
e, a, len (end-of-list bit, AND bit, and length field):
Most significant nibble; defined in the Numeric Operator format in section 3-x.
not (NOT bit):
If set, logical negation of operation.
m (Match bit):
If set, this is a bitwise match operation defined as "(data AND value) == value"; if unset, (data AND value) evaluates to TRUE if any of the bits in the value mask are set in the data.
0 (all 0 bits):
MUST be set to 0 on NLRI encoding and MUST be ignored during decoding

IP Basic Filters (Filter type=1(0x01))
The format of the IP Basic TLV value field is shown in Figure 3-5. The IP header for the VPN case is specified in section 3.5.

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

Figure 3-5 NLRI format for FSv2 IP Filter Type

Where:
order - is an 4 octet field with a value 1-N. The value 0 (zero) is invalid.
dependency filter chain - is an 8 octet field which must be all zero for the IP Basic Filter rules.
length - is a 2 octet field indicating the length of the value field.
value - is a variable field comprised of a sequence of component TLVs:

 +--------------------------------+
 | + ---------------------------+ |
 | + Components TLV+ (variable) + |
 | +----------------------------+ |
 +--------------------------------+

 Figure 3-6 Value Field

  Where the Component TLVs are:

   +----------------------------+
   |  Component Type (1 octet)  |
   +----------------------------+
   |  length (1 octet)          |
   + ---------------------------+
   |  value (variable)          |
   +----------------------------+

Figure 3-7 – IP header Component TLVs

Where:
  Component type: component values are defined in the “Flow Specification Component types” registry for IPv4 and IPv6 by [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6]
  length: length of SubTLV (varies depending on the component type)>
  value: dependent on component type.
Many of the components use the operators [numeric_op] and [bitmask_op] defined in [RFC8955]
The list of valid SubTLV types appears in Table 3-2 for filter type of IP Filters (type=1). Other filters beyond these filters may be defined other filter types (e.g. IP Extended Filters).

Table 3-2 IP SubTLV Types for IP filters
          for IP Basic FSv2

Sub-TLV   Definition
--------  ---------------------
   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-63   Reserved for IP Filter Extensions
  64-150  Reserved for Non-IP Filters
          (L2, MPLS, tunnel) - STD action
 151-191  Reserved for Associated Data
 192-249  FCFS
 250-255  Reserved

Ordering within the IP Basic Filter TLVs
The ordering of components within the value field of the IP Basic TLV is by component types (1-13).
If the SubTLV types are the same, then the value fields are compared using mechanisms defined in [RFC8955] and [RFC8956] and MUST be in ascending order. NLRIs having component TLVs which do not follow the above ordering rules MUST be considered as malformed by a BGP FSv2 propagator. This rule prevents any ambiguities that arise from the multiple copies of the same NLRI from multiple BGP FSv2 propagators. A BGP implementation SHOULD treat such malformed NLRIs as "Treat-as-withdraw" [RFC7606].
See [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6]. for specific details.

FSv2 Components for IP Basic TLVs

IP Destination Prefix (type = 1)
IPv4 Name: IP Destination Prefix (reference: [RFC8955])
IPv6 Name: IPv6 Destination Prefix (reference: [RFC8956])
IPv4 length: Prefix length in bits
IPv4 value: IPv4 Prefix (variable length)
IPv6 length: length of value
IPv6 value: [offset (1 octet)] [pattern (variable)] [padding(variable)]
If IPv6 length = 0 and offset = 0, then component matches every address. Otherwise, length must be offset "less than" length "less than" 129 or component is malformed.

IP Source Prefix (type = 2)
IPv4 Name: IP Source Prefix (reference: [RFC8955])
IPv6 Name: IPv6 Source Prefix (reference: [RFC8956])
IPv4 length: Prefix length in bits
IPv4 value: Source IPv4 Prefix (variable length)
IPv6 length: length of value
IPv6 value: [offset (1 octet)] [pattern (variable)][padding(variable)]
If IPv6 length = 0 and offset = 0, then component matches every address. Otherwise, length must be offset < length < 129 or component is malformed.

IP Protocol (type = 3)
IPv4 Name: IP Protocol IP Source Prefix (reference: [RFC8955])
IPv6 Name: IPv6 Upper-Layer Protocol: (reference: [RFC8956])
IPv4 length: variable
IPv4 value: [numeric_op, value]+
IPv6 length: variable
IPv6 value: [numeric_op, value}+
where the value following each numeric_op is a single octet.

Port (type = 4)
IPv4/IPv6 Name: Port (reference: [RFC8955]), [RFC8956])
Filter defines: a set of port values to match either destination port or source port.
IPv4 length: variable
IPv4 value: [numeric_op, value]+
IPv6 length: variable
IPv6 value: [numeric_op, value]+
where the value following each numeric_op is a single octet.
Note-1: (from FSV1) In the presence of the port component (destination or source port), only a TCP (port 6) or UDP (port 17) packet can match the entire flow specification. If the packet is fragmented and this is not the first fragment, then the system may not be able to find the header. At this point, the FSv2 filter may fail to detect the correct flow. Similarly, if other IP options or the encapsulating security payload (ESP) is present, then the node may not be able to describe the transport header and the FSv2 filter may fail to detect the flow.
The restriction in note-1 comes from the inheritance of the FSv1 filter component for port. If better resolution is desired, a new FSv2 filter should be defined.
Note-2: FSv2 component only matches the first upper layer protocol value.

Destination Port (type = 5)
IPv4/IPv6 Name: Destination Port (reference: [RFC8955]), [RFC8956])
Filter defines: a list of match filters for destination port for TCP or UDP within a received packet
Length: variable
Component Value format: [numeric_op, value]+

Source Port (type = 6)
IPv4/IPv6 Name: Source Port (reference: [RFC8955]), [RFC8956])
Filter defines: a list of match filters for source port for TCP or UDP within a received packet
IPv4/IPv6 length: variable
IPv4/Ipv6 value: [numeric_op, value]+

ICMP Type (type = 7)
IPv4: ICMP Type (reference: [RFC8955])
Filter defines: Defines: a list of match criteria for ICMPv4 type
IPv6: ICMPv6 Type (reference: [RFC8956])
Filter defines: a list of match criteria for ICMPv6 type.
IPv4/IPv6 length: variable
IPv4/IPv6 value: [numeric_op, value]+

ICMP Code (type = 8)
IPv4: ICMP Type (reference: [RFC8955])
Filter defines: a list of match criteria for ICMPv4 code.
IPv6: ICMPv6 Type (reference: [RFC8956])
Filter defines: a list of match criteria for ICMPv6 code.
IPv4/IPv6 length: variable
IPv4/IPv6 value: [numeric_op, value]+

TCP Flags (type = 9)
IPv4/IPv6: TCP Flags Code (reference: [RFC8955])
Filter defines: a list of match criteria for TCP Control bits
IPv4/IPv6 length: variable
IPv4/IPv6 value: [bitmask_op, value]+
Note: a 2 octets bitmask match is always used for TCP-Flags

Packet length (type = 10 (0x0A))
IPv4/IPv6: Packet Length (reference: [RFC8955], [RFC8956])
Filter defines: a list of match criteria for length of packet (excluding L2 header but including IP header).
IPv4/IPv6 length: variable
IPv4/IPv6 value: [numeric_op, value]+
Note:[RFC8955] uses either 1 or 2 octet values.

DSCP (Differentiaed Services Code Point)(type = 11 (0x0B))
IPv4/IPv6: DSCP Code (reference: [RFC8955], [RFC8956])
Filter defines: a list of match criteria for DSCP code values to match the 6-bit DSCP field.
IPv4/IPv6 length: variable
IPv4/IPv6 value: [numeric_op, value]+
Note: This component uses the Numeric Operator (numeric_op) described in [RFC8955] in section 4.2.1.1. Type 11 component values MUST be encoded as single octet (numeric_op len=00).
The six least significant bits contain the DSCP value. All other bits SHOULD be treated as 0.

Fragment (type = 12 (0x0C))
IPv4/IPv6: Fragment (reference: [RFC8955], [RFC8956])
Filter defines: a list of match criteria for specific IP fragments.
Length: variable
Component Value format: [bitmask_op, value]+
Bitmask values are:

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

Where:
DF (don’t fragment): match If IP header flags bit 1 (DF) is 1.
IsF(is a fragment other than first: match if IP header fragment offset is not 0.
FF (First Fragment): Match if [RFC0791] IP Header Fragment offset is zero and Flags Bit-2 (MF) is 1.
LF (last Fragment): Match if [RFC0791] IP header Fragment is not 0 And Flags bit-2 (MF) is 0
0: MUST be sent in NLRI encoding as 0, and MUST be ignored during reception.

Flow Label(type = 13 (0xOD))
IPv4/IPv6: Fragment (reference: [RFC8956])
Filter defines: a list of match criteria for 20-bit Flow Label in the IPv6 header field.
Length: variable
Component Value format: [numeric_op, value]+

FSv2 Actions for FSv2 IP Basic
The IP Basic FSv2 allows FSv2 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]. The FSv2-EC actions cannot be ordered by the user and some FSv2-EC interaction cause conflicting actions.
This section defines the FSv2-EC actions as FSv1 actions plus one additional action (Action Chain Ordering). This setion reviews the existing FSv2-EC action formats (section 3.3.1), the interaction between existing FS-EC actions (section 3.3.2), and the FSv2 default order of actions (section 3.2.3). For those familar with the FSv1 actions, Tables 3-7 and 3-8 in section 3.3.3 have the default order for FSv2-EC actions.
Section 3.4 defines Action Chain Ordering (ACO) FSv2-EC. The ACO FSv2-EC provides two actions. The first action signals if implementation specific ordering of FS-EC actions replaces the default FSv2 ordering. The second is handles an a ction failiure if multiple actions are attached to a filter match. If there are multiple actions are attached in a chain, the first action could fail. The ACO FSv2-EC aids the transition between FSv1 actions which are ordered uniquely by each implementation, and the FSv2 actions which use a global default.
The implementer and the operator deploying need to be aware of default order of actions and the interactions between any set of FSv2 actions.

FSv2 Extended Community Actions inherited from FSv1
This section reviews FSv1 actions in Extended Communities (IPv4 and IPv6) and conflicts FSv1 actions. The FSv2 IP Basic uses these basic FSv1 with plus one additional FSv2 specific FS-EC. The additional FSv2 Extended Community (FSv2-EC) is the Action Chain Ordering (ACO) Extended Community (ACO-EC).
This section first reviews the Extended Communities format (Figure 3-9) and describes where Flow Specification (FS) related Extended communities (EC) have been allocated (see Table 3-3 and Table 3-4.)
The format of the Extended Community for IPv4 defined in [RFC4360] is shown in Figure 3-9 with 2 octet type that is split into a high byte and low byte. The format of the IPv4 Extended Community is shown in Figure 3-10.

  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

The high byte of the Type field of the Extended Community (EC) has the definitions found in Table 3-3. Only Sume of these are defined to be used for FSv1. Only the FSv1 Extended Communities (FSv1-ECs) can be used with the FSv2 NLRI which are listed as "yes". One oddity is that the FS specification for interface sets allocated the "high byte", but did not register any sub-types since the draft was not approved by IDR (see *1). The high byte for FS Redirect/Mirror (RDIPv4C) is requested by the latest version of [I-D.ietf-idr-flowspec-redirect-ip] to be deprecated.
The remainder of the FS-EC allocations are split between three types: redirection function, generic, and SFC. The sub-sections in this section review these three types of FS-EC.

Table 3-3 Transitive Extended Community types
   (high byte of type field)

H-byte   FSv1 Description        Name    S-Type FS document
======   ==================      ====    ====== ==========
0x00     Transitive 2-octet AS   T-2AS    yes    No
0x01     Transitive IPv4         T-IPv4   yes    yes: RDIP
0x02     Transitive 4-octet      T-4AS    yes    No
0x03     Transitive opaque       T-OPQ    yes    No
0x06     EVPN (sub-types)        EVPN     yes    No
0x07     FS 4-octet AS and Group T-ASG    yes    yes: ifset *1
0x08     FS Redirect/Mirror      RDIPv4C  yes    yes: RDIP *2
0x09     FS Redirect to          RGID     yes    yes: RGID *3
            indirection ID
0x0a     Transport class         TP-Class no     no
0x0b     FSv1 SFC                T-SFC    yes    yes: RFC9015
0x0c     SRv6 MUP EC             T-SRv6M  no     no
0x80     Generic Part-1          T-GenP1  yes    yes: RFC8955
0x81     Generic Part-2          T-GenP2  yes    yes: RFC8955
0x82     Generic Part-3          T-GenP3  yes    yes: RFC8955

*1 -
No sub-byte registry formed
*2 -
Deprecated based on [I-D.ietf-idr-flowspec-redirect-ip]
*3 -
No sub-byte registry formed [I-D.ietf-idr-flowspec-path-redirect]

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

H-L      FSv1 Description               Name     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

References:
ifset:
[I-D.ietf-idr-flowspec-interfaceset]
RDIP:
[I-D.ietf-idr-flowspec-redirect-ip]
RGID:
[I-D.ietf-idr-flowspec-path-redirect]
RFC9015:
[RFC9015]
RFC8955:
[RFC8955]
The Transitive IPv6-Address-Specific Extended Community encodes the Flow Specification actions in the Extended Community format specified in [RFC5701] shown in Figure 3-10. Table 3-3 lists the 4 octet format for high-byte and low-byte. Note that there are two allocations for redirect from IPv6.

  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-5
Transitive IPv6-Address-Specific Extended Community Types

H-L byte  FSv1 Description        Name     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

References:
RDIP:
[I-D.ietf-idr-flowspec-redirect-ip]
RFC8956:
[RFC8955]

Conflicts between FSv2 actions inherited from FSv1 Actions

Redirection FS-EC and IPv6 FS-EC Conflicts
The following FS defines redirection functions in Transitive EC
[RFC8955]
defines redirection to VRF (denoted at RDIP). The copy function is done as a second FS-EC.
[RFC8956]
defines redirection to VRF (denoted as RDIPv6). the copy function is done as a second FS-EC
[I-D.ietf-idr-flowspec-redirect-ip]:
defines a copy funtion is defined to be part of the same function based on a C-Flag where if C=0 redirect the base packet, and if C=1 the redirect applies to copies. This function is defined for IPv4 forms and IPv6 forms.
[I-D.ietf-idr-flowspec-path-redirect]:
The Generalized redirect redirects generalized ID whose function is identified by the ID-Type field. A copy flag has the same function as the [I-D.ietf-idr-flowspec-redirect-ip]. The final flag Field is a 4 byte field specifying a sequence number for ordering of multiple global indirection FS-EC. This sequence number does not apply to other forms of redirect.
[I-D.ietf-idr-flowspec-interfaceset]:
defines a group of interface upon which the flow specification rules (filters and actions) are to be applied. This interactions with all redirect functions.
Redirect is a major function for FS-EC and the redirect functions have a potential to interact with unexpected results - if the order switches. FSv2-EC use a deterministic order. The Action Chain Order (ACO) FSv2-EC provides a means for the originator and propagator to signal if the order is implementation specific (that is set by configuration knob) or if FSv2-EC order.

FSv1-EC conflicts in transmission Rate limits and marking
Besides redirect conflicts, FSv1 has conflicts between the transmission rate limit (bytes versus packet) and FSv1 directed at a single interface group.

                  Table 3-6
  Conflicts between FSv2 Transitive Generic IPv4 actions

H-L byte
Value    Description                   Name    Potential Conflicts
=======  ======================        ======  ====================
0x07-02  FS for Interface Group        TAIS    TRB, TA, TM, TRP
0x80-06  Traffic rate limit by bytes   TRB     TRP
0x80-07  Traffic Action                TA      redirect, TAIS
0x80-09  Traffic mark DSCP             TM      TAIS
0x80-0C  Traffic rate limit by packets TRP     TRB

Ridirect FSv1-EC include: RDIP, RDv6, RDIPv4, RDIPv6, and RGID/

Key for table
TAIS:
FSV1 Traffic actions (copy, sample, drop, and terminal (stop processing)) [RFC8955]
TRB:
Traffic rate (limit) by bytes [RFC8955]
TA:
Traffic action (sample or copy) [RFC8955]
TRP:
FSV1 traffic rate (limit) by packet [RFC8955]
RDIP:
FSv1 rt-redirect [RFC8955]
RDv6:
FSv1 rt-direct [RFC8956]
RDIPv4:
Redirect IP (direct or copy) [I-D.ietf-idr-flowspec-redirect-ip]
RDIPv6:
Redirect IPv6 (direct or copy) [I-D.ietf-idr-flowspec-redirect-ip]
RGID:
Redirect to Generalized ID (direct or copy) [I-D.ietf-idr-flowspec-path-redirect]
TMDS:
Flow spec Remark DSCP [RFC8955]

Default Ordering for FSv2 Extended Community Actions
One of the issue that started the FSv2 work was the fact that actions interacted. These interactions might occur when both actions performed their duties which caused conflicting results. One example of a potentially unexpected interaction is when the FSv2 for rate limiting by packet (TRP) combines with the FSv2-EC action for rate limiting by byte (TRB).

               Table 3-7
Default order for Processing Transitive IPv4 FSv2-EC Communities
      High-Low byte of Transitive FS-EC

#   H-L      FSv1 Description               Name     FS document
== ========  =============================  =======  ==========
 1 0x80-xx   Action Chain ordering          ACO      [this document]
 2 0x80-06   Traffic rate limit by bytes    TRB      RFC8955
 3 0x80-07   Traffic Action                 TA       RFC8955
             (sample, terminal)
 4 0x80-08   Redirection to VRF (2 AS form) RDIP     RFC8955
 5 0x80-09   Traffic mark DSCP              TM       RFC8955
 6 0x80-0C   Traffic rate limit by packets  TRP      RFC8955
 7 0x81-08   Redirect to VPN (IPv4 form)    RDIP     RFC8955
 8 0x81-08   Redirect to VPN (4 AS form)    RDIP     RFC8955

 9 0x01-0C   Transitive IPv4                RDIPv4   RDIP
10 0x07-02   FSv1 for an Interface set      TAIS     ifset
11 0x09-xx   Redirect to Indirection ID     RGID     RGID
12 0x0b-00   SFC Reserved                   SFC-R    RFC9015
13 0x0b-01   SFVC SFIR POOL Identifier      SFIR-PI  RFC9015
14 0x0b-02   SFC MPLS label stack Swapping  SFC-MPLS RFC9015
             or stacking labels

References:
ifset:
[I-D.ietf-idr-flowspec-interfaceset]
RDIP:
[I-D.ietf-idr-flowspec-redirect-ip]
RGID:
[I-D.ietf-idr-flowspec-path-redirect]
RFC9015:
[RFC9015]
RFC8955:
[RFC8955]

                  Table 3-8
Default Order Transitive IPv6-Address-Specific Extended Communities

#     H-type  FSv2 Description     Name    FS document
====  ======  ==================   =======  ==========
1-14          All IPv4 FS-EC       (see table 3-7)
15    0x000C  Redirect to IPv6     RDIPv6C   RDIP
16    0x000D  Redirect to IPv6     RDIPv6   [RFC8956]

The IPv6 redirect functions are ordered after all
FSv2-EC for IPv4.

References:
RDIP:
[I-D.ietf-idr-flowspec-redirect-ip]
RFC8956:
[RFC8955]

Action Chain Ordering FSv2 Extended Community (ACO FSv2-EC)
Summary:
Action Chain Ordering sets the default order dependency and failure mode within the chain of actions engaged by a filter match.
Description:
One of the issues with FSv1 is the lack of a clear definition on what happens if multiple actions interact. Two types of interactions cn occur.
Two conflicting actions on traffic flow
If two actions modify a single packet or a traffic flow, the order the action operate may be important. A deterministic order of action processing allows an implementation to be able to count on which actions occur first. The previous section of this document set default ordering for FSv2-EC so that implementation can count on which actions (if multiple actions are present), is enacted first. FSv1 implementation today provide their own ordering of FSv1 Actions. In order to provide a migration path, the Action Chain Ordering (ACO) FSv2-EC ACO-Dependency flags indicate if an implementation is using proprietary intstead of FSv2 default ordering.
A second way an FSv2 action can interact is if the first action fails.
For example, if the first action was copy (via a mirror action) and the second action is the packet. If the first action fails, should the second action still occur? The correct answer depends on the FSv2 application. If the order of the two actions is drop the packet and then mirror, the mirror function would not copy any packets. The Action Chain Ordering (FSV2-EC) AC-Failure value specifies what occurs when an action failes.
Encoding:
The Generic Transitive encoding is shown in figure 3-11 with the field definitions below.

 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     |ACO-dependency |  AC-Failure   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         AC-Failure value  (4 octets)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3-11

where:
Type high:
This 1 octet field has a value of 0x80 For the Generic Transitive EC.
Type low:
This one octet field identifies the ACO-Action. The value is TBD4.
ACO Dependency
This field indicates whether the FS-EC order is either the pre-defined order or an implementation specific order.
0 = default order and interaction.
For FSv2-EC this means a pre-defined order and inter-dependency.
1 = Implementation specific order and interaction.
The implementation specific order is outside the scope of this document
AC-failure-type –
1 octet byte that determines the action on failure. Actions may succeed or fail and an Action chain must deal with it. The default value stored for an action chain that does not have this action chain is “stop on failure”.
where AC-Failure types are
0x00 –
stop on failure
0x01 –
continue on failure (best effort on actions)
0x02 –
conditional stop on failure depending on AC-Failure value.
0x03 –
rollback. This means do all action or no actions depending in AC-Failure value
AC-Failure value -
For the ACO functionality defined in this specification are the following
Default value (0, 0x00000000) -
Default value for conditional stop is to stop on failures. Default value for rollback is to "do no actions".
All other values -
All other values are outside the scope of this specification.

Validation and Ordering of NLRI

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], and the specific additions made for SFC NLRI [RFC9015], and L2VPN NLRI [I-D.ietf-idr-flowspec-l2vpn].
To provide clarity, the full validation process for flow specification routes (FSv1 or FSv2) is described in this section 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 “TREAT as WITHDRAW” [RFC7606].

Validation of FS NLRI (FSv1 or FSv2)
Flow specifications received from a BGP peer that are accepted in the respective Adj-RIB-In are used as input to the route selection process. Although the forwarding attributes of the two routes for tbe same prefix may be the same, BGP is still required to perform its path selection algorithm in order to select the correct set of attributes to advertise.
The first step of the BGP Route selection procedure (section 9.1.2 of [RFC4271] is to exclude from the selection procedure routes that are considered unfeasible. In the context of IP routing information, this is used to validate that the NEXT_HOP Attribute of a given route is resolvable.
The concept can be extended in the case of the Flow Specification NLRI to allow other validation procedures.
The FSv2 validation process validates the FSv2 NLRI with following unicast routes received over the same AFI (1 or 2) but different SAFIs:
FSv2 received over SAFI=TBD1
FSv1 received over SAFI=133 are be validated against SAFI=1. Similarly, FSv2 routes received over SAFI=TBD1 will be validated against SAFI=1.
FSv2 received over SAFI=TBD2
FSv1 received over SAFI=134 are validated against SAFI=128, and FSv2 received over SAFI=TBD2 will be validated against SAFI=128.
FSv2 received with AFI = 31
The FSV2 routes received with (AFI=31, SAFI=TBD1) will be validated against SAFI=1. The FSv2 received with (AFI=31, SAFI=TBD2) will be validated against SAFI=128.
FSv2 L2 routes passed in (AFI=6, SAFI=TBD1) and L2VPN routes passed in (AFI=25, SAFI=TBD2).
FSv2 L2 routes -
validate (AFI=6, SAFI=TBD1) against (AFI=1, SAFI=1).
FSv2 L2VPN routes -
validate (AFI=256, SAFI=TBD2) against (AFI=1, SAFI=128>
This is similar to FSv1. -
The FSv1 L2 validated L2 routes passed in (AFI=6, SAFI=133) against (AFI=1, SAFI=1) and the L2VPN routes (AFI=25, SAFI=134) are validated against (AFI=1, SAFI=128).
In the absence of explicit configuration, a Flow specification NLRI (FSv1 or FSv2) MUST be validated such that it is considered feasible if and only if all of the conditions are true:
a) A destination prefix component is embedded in the Flow Specification,
b) One of the following conditions holds true:
  1. The originator of the Flow Specification matches the originator of the best-match unicast route for the destination prefix embedded in the flow specification (this is the unicast route with the longest possible prefix length covering the destination prefix embedded in the flow specification).
  2. The AS_PATH attribute of the flow specification is empty or contains only an AS_CONFED_SEQUENCE segment [RFC5065].
    2a.This condition should be enabled by default.
    2b.This condition may be disabled by explicit configuration on a BGP Speaker,
    2c.As an extension to this rule, a given non-empty AS_PATH (besides AS_CONFED_SEQUENCE segments) MAY be permitted by policy].
c) There are no “more-specific” unicast routes when compared with the flow destination prefix that have been received from a different neighbor AS than the best-match unicast route, which has been determined in rule b.
However, part of rule a may be relaxed by explicit configuration, permitting Flow Specifications that include no destination prefix component. If such is the case, rules b and c are moot and MUST be disregarded.
By “originator” of a BGP route, we mean either the address of the originator in the ORIGINATOR_ID Attribute [RFC4456] or the source address of the BGP peer, if this path attribute is not present.
A BGP implementation MUST enforce that the AS in the left-most position of the AS_PATH attribute of a Flow Specification Route (FSv1 or FSv2) received via the Exterior Border Gateway Protocol (eBGP) matches the AS in the left-most position of the AS_PATH attribute of the best-match unicast route for the destination prefix embedded in the Flow Specification (FSv1 or FSv2) NLRI.
The best-match unicast route may change over time independently of the Flow Specification NLRI (FSv1 or FSv2). Therefore, a revalidation of the Flow Specification MUST be performed whenever unicast routes change. Revalidation is defined as retesting rules a to c as described above.

Validation of Flow Specification Actions for IP Basic
FSv2 may be mapped to actions using Extended Communities for the IP Basic Functionality. The ordering of precedence for these actions in the precedence of the FSv2 NLRI action TLV values (lowest to highest).
Actions may conflict, duplicate, or complement other actions. An example of conflict is the packet rate limiting by byte and by packet. An example of a duplicate is the request to copy or sample a packet under one of the redirect functions. This document defines the potential conflicts or duplications for existing FSv1 actions.
Specifications for new FSv2 actions outside of this specification MUST specify interactions or conflicts with any existing FSv2 actions
Well-formed syntactically correct actions defined in Extended Communities are linked to the filtering rules defined in the NLRI in UPDATE packet. Multiple syntactically correct FSv2 actions from Extended Communities can be linked to one filter rule. These actions will occur in the default FSv2 order if the ACO Extended Community with the "implementation specific" indicator is not attached.
If one action in the ordered list fails, the default FSv2 procedure is for the action process for this rule to stop and flag the error via system management. The action chain may continue if one of two things exist:
a) ACO community is attached to the FSv2 filter with an AC-Failure type of "continue on failure (0x01), or
b) local configuration that indicates a FSV2 action should continue after errors.
Implementations MAY wish to log the actions taken by FS actions (FSv1 or FSv2).

Error handling and Validation
The following two error handling rules must be followed by all BGP speakers which support FSv2:
- FSv2 NLRI having TLVs which do not have the correct lengths or syntax must be considered MALFORMED.
- FSv2 NLRIs having TLVs which do not follow the above ordering rules described in section 4.1 MUST be considered as malformed by a BGP FSv2 propagator.
The above two rules prevent any ambiguity that arises from the multiple copies of the same NLRI from multiple BGP FSv2 propagators.
A BGP implementation SHOULD treat such malformed NLRIs as ‘Treat-as-withdraw’ [RFC7606]
An implementation for a BGP speaker supporting both FSv1 and FSv2 MUST support the error handling for both FSv1 and FSv2.

Ordering for FSv2 Filters and Actions
Flow Specification v2 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 that match condition.
This section describes how to order FSv2 filters received from a peer prior to transmission to another peer. The same ordering should be used for the ordering of forwarding filtering installed based on only FSv2 filters.
Section x.x describes how a BGP peer that supports FSv1 and FSv2 should order the flow specification filters during the installation of these flow specification filters into FIBs or firewall engines in routers.
The BGP distribution of FSv1 NLRI and FSv2 NLRI and their associated path attributes for actions (Wide Communities and Extended Communities) is “ships-in-the-night” forwarding of different AFI/SAFI information. This recommended ordering provides for deterministic ordering of filters sent by the BGP distribution.

Ordering of FSv2 NLRI Filters
The basic principles regarding ordering of rules are simple:
1) Rule-0 (zero) is defined to be 0/0 with the “permit-all” action
  BGP peers which do not support flow specification permit traffic for routes received. Rule-0 is defined to be “permit-all” for 0/0 which is the normal case for filtering for routes received by BGP.
  By configuration option, the “permit-all” may be set to “deny-all” if traffic rules on routers used as BGP must have a “route” AND a firewall filter to allow traffic flow.
2) FSv2 rules are ordered based on the user-defined order numbers specified in the FSv2 NLRI (rules 1-n).
3) If multiple FSv2 NLRI have the same user-defined order, then the filters are ordered by type of FSv2 NRLI filters (see Table 1, section 4) with lowest numerical number have the best precedence.
  For the same user-defined order and the same value for the FSv2 filters type, then the filters are ordered by FSv2 the component type for that FSv2 filter type (see Tables 3-6) with the lowest number having the best precedence.
  For the same user-defined order, the same value of FSv2 Filter Type, and the same value for the component type, then the filters are ordered by value within the component type. Each component type defines value ordering.
  For component types inherited from the FSv1 component types, there are the following two types of comparisons:
    FSv1 component value comparison for the IP prefix values, compares the length of the two prefixes. If the length is different, the longer prefix has precedence. If the length is the same, the lower IP number has precedence.
    For all other FSv1 component types, unless specified, the component data is compared using the memcmp() function defined by [ISO_IEC_9899]. For strings with the same length, the lowest string memcmp() value has precedence. For strings of different lengths, the common prefix is compared. If the common string prefix is not equal, then the string with the lowest string prefix has higher precedence. If the common prefix is equal, the longest string is considered to have higher precedence
Notes:
- Since the user can define rules that re-order these value comparisons, this order is arbitrary and set to provide a deterministic default.

Ordering of the Actions for IP Basic
The FSv2 specification for IP Basic only allows for Extended Community actions. Ordering of Actions associated with an IP Basic filter is based on the Action type value (low byte) of the Extended Community. The action type values are listed in ascending numerical order in Table 3-11 for IPv4 and Table 3-12 for IPv6. Action type zero (0x00) is not valid.
The mixture of Extended Community action types and action types associated with a Community path attribute is outside the scope of this document.

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.

Scalability and Aspirations for FSv2
Operational issues drive the deployment of BGP flow specification as a quick and scalable way to distribute filters. The early operations accepted the fact validation of the distribution of filter needed to be done outside of the BGP distribution mechanism. Other mechanisms (NETCONF/RESTCONF or PCEP) have reply-request protocols.
These features within BGP have not changed. BGP still does not have an action-reply feature.
NETCONF/RESTCONF latest enhancements provide action/response features which scale. The combination of a quick distribution of filters via BGP and a long-term action in NETCONF/RESTCONF that ask for reporting of the installation of FSv2 filters may provide the best scalability.
The combination of NETCONF/RESTCONF network management protocols and BGP focuses each protocol on the strengths of scalability.
FSv2 will be deployed in webs of BGP peers which have some BGP peers passing FSv1, some BGP peers passing FSv2, some BGP peers passing FSv1 and FSv2, and some BGP peers not passing any routes.
The TLV encoding and deterministic behaviors of FSv2 will not deprecate the need for careful design of the distribution of flow specification filters in this mixed environment. The needs of networks for flow specification are different depending on the network topology and the deployment technology for BGP peers sending flow specification.
Suppose we have a centralized RR connected to DDoS processing sending out flow specification to a second tier of RR who distribute the information to targeted nodes. This type of distribution has one set of needs for FSv2 and the transition from FSv1 to FSv2
Suppose we have Data Center with a 3-tier backbone trying to distribute DDoS or other filters from the spine to combinational nodes, to the leaf BGP nodes. The BGP peers may use RR or normal BGP distribution. This deployment has another set of needs for FSv2 and the transition from FSv1 to FSV2.
Suppose we have a corporate network with a few AS sending DDoS filters using basic BGP from a variety of sites. Perhaps the corporate network will be satisfied with FSv1 for a long time.
These examples are given to indicate that BGP FSv2, like so many BGP protocols, needs to be carefully tuned to aid the mitigation services within the network. This protocol suite starts the migration toward better tools using FSv2, but it does not end it. With FSv2 TLVs and deterministic actions, new operational mechanisms can start to be understood and utilized.
This FSv2 specification is merely the start of a revolution of work – not the end.

Optional Security Additions
This section discusses the optional BGP Security additions for BGP-FS v2 relating to BGPSEC [RFC8205] and ROA [RFC9582].

BGP FSv2 and BGPSEC
Flow specification v1 ([RFC8955] and [RFC8956]) do not comment on how BGP Flow specifications to be passed BGPSEC [RFC8205] BGP Flow Specification v2 can be passed in BGPSEC, but it is not required.
FSv1 and FSv2 may be sent via BGPSEC.

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.

IANA Considerations
This section complies with [RFC7153].

Flow Specification V2 SAFIs
IANA is requested to assign two SAFI Values in the registry at https://www.iana.org/assignments/safi-namespace from the Standard Action Range as follows:

     Table 7-1 SAFIs

     Value   Description      Reference
     -----   -------------    ---------------
      TBD1   BGP FSv2        [this document]
      TBD2   BGP FSv2 VPN    [this document]

BGP Capability Code
IANA is requested to assign a Capability Code from the registry at https://www.iana.org/assignments/capability-codes/ from the IETF Review range as follows:

   Table 7-2 - Capability Code

   Value   Description            Reference       Controller
   -----  ---------------------  ---------------  ----------
    TBD3  Flow Specification V2  [this document]  IETF

Generic Transitive Extended Community
IANA is requested to assign a type value from the "Generic Transitive Extended Community Sub-Types" registry at https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml

   Table 7-3 - Generic Transitive Extended Community

   Value   Description                Reference       Controller
   -----  --------------------------  ---------------  ----------
    TBD4  FSv2 Action Chain Ordering  [this document]  IETF

   The requested value is "0x01".

FSv2 IP Filters Component Types
IANA is requested to create a new "BGP FSv2 Component Types" registry and indicate [this draft] as a reference. The following assignments in the FSv2 IP Filters Component Types Registry shold be made.

   Table 7-5 - Flow Specification

   Registry Name: BGP FSv2 Component Types
   Reference: [this document]
   Registration Procedures: 0x01-0x3FFF Standards Action.

   Value  Description         Reference
   -----  ------------------- ------------------------
    1     Destination filter  [RFC8955][RFC8956][this document]
    2     Source Prefix       [RFC8955][RFC8956][this document]
    3     IP Protocol         [RFC8955][RFC8956][this document]
    4     Port                [RFC8955][RFC8956][this document]
    5     Destination Port    [RFC8955][RFC8956][this document]
    6     Source Port         [RFC8955][RFC8956][this document]
    7     ICMP Type [v4 or v6][RFC8955][RFC8956][this document]
    8     ICMP Code [v4 or v6][RFC8955][RFC8956][this document]
    9     TCP Flags [v4]      [RFC8955][RFC8956][this document]
   10     Packet Length       [RFC8955][RFC8956][this document]
   11     DSCP marking        [RFC8955][RFC8956][this document]
   12     Fragment            [RFC8955][RFC8956][this document]
   13     Flow Label          [RFC8956][this document]

FSV2 NLRI TLV Types
IANA is requested to create the a new registries on a new "Flow Specification v2 TLV Types” web page.

   Table 7-6 FSv2 TLV types

   Registry Name: BGP FSv2 TLV types
   Reference: [this document]
   Registration Procedures: 0x01-0x3FFF Standards Action.

    Type          Description              Reference
    ----          ----------------------   ------------
    0x00          Reserved                 [this document]
    0x01          IP traffic rules         [this document]
    0x02          Extended IP Rules        [this document]
    0x03          MPLS Traffic Rules       [this document]
    0x04          L2 Traffic rules         [this document]
    0x05          SFC Traffic rules        [this document]
    0x06          Tunneled traffic rules   [this document]
    0x08-0x3FFF   Unassigned               [this document]
    0x4000-0x7FFF Vendor specific          [this document]
    0x8000-0xFFFF Reserved                 [this document]

Security Considerations
The use of ROA improves on [RFC8955] by checking to see of the route origination. This check can improve the validation sequence for a multiple-AS environment.
>The use of BGPSEC [RFC8205] to secure the packet can increase security of BGP flow specification information sent in the packet.
The use of the reduced validation within an AS [RFC9117] can provide adequate validation for distribution of flow specification within a single autonomous system for prevention of DDoS.
Distribution of flow filters may provide insight into traffic being sent within an AS, but this information should be composite information that does not reveal the traffic patterns of individuals.

Normative References

Informative References
[I-D.ietf-idr-flowspec-v2]
[RFC8955]
[RFC8956]
[RFC9117]
[RFC4271]
[RFC8205]
[RFC8206]
[I-D.hares-idr-bgp-community-attribute]
[RFC6241]
[RFC8040]
[RFC9582]
[RFC2119]
[RFC8174]
[RFC4360]
[I-D.ietf-idr-flowspec-l2vpn]
[I-D.ietf-idr-flowspec-nvo3]
[RFC4760]
[I-D.ietf-idr-flowspec-srv6]
[RFC7606]
[RFC0791]
[RFC5701]
[I-D.ietf-idr-flowspec-redirect-ip]
[I-D.ietf-idr-flowspec-path-redirect]
[I-D.ietf-idr-flowspec-interfaceset]
[RFC9015]
[RFC5065]
[RFC4456]
[RFC7153]