BGP Flow Specification Version 2 - for Basic IP

2.1. 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  |
       | AFIs: 1 and 2     |      | Communities      |
       | SAFI 133, 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

2.2. 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) [defined in FSv2-DDOS],¶

• IPv6 (AFI=2, SAFI=TBD2) [defined in FSv2-DDOS],¶

• L2 (AFI=6, SAFI=TDB1) [defined in FSv2-L2],¶

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

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

• BGP/MPLS L2VPN (AFI=25, SAFI=TDB2) [defined in FSv2-L2],¶

• SFC: (AFI=31, SAFI=TBD1) [defined in FSv2-SFC], and¶

• SFC VPN (AFI=31, SAFI=TBD2) [defined in FSv2-SFC].¶

An IDR specification for tunneled traffic is in [I-D.ietf-idr-flowspec-nvo3]. This Draft was original target for FSv1, and will be considered for 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 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.¶

Figure 2-2 provides a logical diagram of the FSv2 structure¶

       +--------------------------------+
       |          Rule Group            |
       +--------------------------------+
         ^          ^                  ^
         |          |---------         |
         |                   |         ------
         |                   |               |
+--------^-------+   +-------^-----+     +---^-----+
|      Rule1     |   |     Rule2   | ... |  Rule-n |
+----------------+   +-------------+     +---------+
                      :  :   :    :
    :.................:  :   :    :
    :        |...........:   :    :
 +--V--+ +--V-------+        :    :
 |order| |identifier| .......:    :
 +-----+ +----------+ :           :
                      :           :
   +------------------V--+  +-----V----------------+
   |Rule Match condition |  | Rule Action          |
   +---------------------+  +----------------------+
    :      :     :    :       :      :   :   :   |
 +--V--+   :     :    :    +--V---+  :   :   :   V
 | Rule|   :     :    :    |action|  :   :   :  +-----------+
 | name|   :     :    :    |order |  :   :   :  |action name|
 +-----+   :     :    :    +------+  :   :   :  +-----------+
           :     :    :              :   :   :.............
           :     :    :              :   :                :
      .....:     .    :.....       ..:   :......          :
      :          :         :       :           :          :
 +----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

2.3. Flow Specification v2 (FSv2) Series of Specifications

The full FSV2 information is contained in [I-D.ietf-idr-flowspec-v2].¶

Feedback from the implementers indicate that the Flow Specification v2 needs to broken into drafts based on the use cases the technology supports. These include IPv4/IPv6 IP Basic Filters for DDOS, IPv4/IPv6 filters beyond DDOS, BGP/MPLS IPv4 VPN, BGP/MPLS IPv6 VPN, BGP/MPLS L2VPN, Segment routing (SRMPLS, SRv6), SFC, SFC VPN, L2, L2 VPNs, and tunneled traffic (e.g., nv03 WG tunnels).¶

The following is the list of planned drafts:¶

• FSv2 IP Basic (draft-hares-idr-fsv2-ip-basic)¶

• FSv2 More IP Filters ([I-D.hares-idr-fsv2-more-ip-filters])¶

• FSv2 More IP Actions ([I-D.hares-idr-fsv2-more-ip-actions])¶

• FSv2 Non-IP Filters (draft-hares-idr-fsv2-non-ip-Filters)¶

• FSv2 Non-IP Actions (draft-hares-idr-fsv2-non-ip-actions)¶

The sections below describe each draft.¶

3.1. 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+                          |
 | +============================+ |
 | | order (4 octets)           | |
 | +----------------------------+ |
 | | identifier (4 octets)      | |
 | +----------------------------+ |
 | + FSv2 Filter type (2 octet) + |
 | +----------------------------+ |
 | + length TLVs (2 octet)      + |
 | + ---------------------------+ |
 | + value (variable)           + |
 | +----------------------------+ |
 +-------------------------------+

 Figure 3-1 - NLRI format for FSv2

where:¶

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

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

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

• identifier: identifier for the rule (used for NM/Logging) (4 octets)¶

• 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. For example, the IP Traffic Rules defines the¶

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.¶

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

3.2. Basic IP Filters

 +-------------------------------+
 | NLRI length (2 octets)        |
 +-------------------------------+
 | TLVs+                         |
 | +===========================+ |
 | | order (4 octets)          | |
 | +---------------------------+ |
 | | identifier (4 octets)     | |
 | +---------------------------+ |
 | + FSv2 Filter type = 1      + |
 | +---------------------------+ |
 | + length TLVs (2 octet)     + |
 | + --------------------------+ |
 | + value (variable)          + |
 | +---------------------------+ |
 +-------------------------------+

Figure 3-2 NLRI format for FSv2 IP Filter Type

 +--------------------------------+
 | + ---------------------------+ |
 | + Components TLVs (variable) + |
 | +----------------------------+ |
 +--------------------------------+

  Where the Component TLVs are:

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

Figure 3-3 – IP header Component TLVs

Table 3-1 IP SubTLV Types for IP filters
          for IP Basic FSv2
SubTLV
-type     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 -    TTL
  15-63   reserved for IP Extensions
          (standards action)

  64-127  Reserved for Non-IP Filters
 128-191  Reserved for Standard Action
 192-249  FCFS
 250-255  Reserved

Table 3-2 IP SubTLV types for non-IP Filters

SubTLV   IP SubTLV types
-type    Definition
======   ===========
  64      Parts of SID
  65      MPLS LAbel Match-1
  66      MPLS Label Match-2
  67-127  Match reserved for Non-IP
  128-191 reserved (standards action)
  192-249 FCFS
  250-    FSv2 Filter Error handling
 251-255  Reserved

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

3.3. FSv2 Actions for IP Basic

The full FSV2 [I-D.ietf-idr-flowspec-v2] specifies that FSv2 actions can be sent in Extended Communities or a Community attribute with the FSv2 community type. The IP Basic FSv2 only allows FSv2 actions to be sent in an Extended Community (FSv2-EC)¶

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 interact. . This section defines the FSv2-EC actions for FSv2 IP Basic by defining existing FSv2-EC action formats, the interaction between actions, and the default order of actions.¶

The FSv2 Action Chain Ordering Extended Community (AO-EC) signals if the defaults for the FSv2 Extended Community action ordering and interactions are being ignored, and an implementation specific ordering being used instead. This Action Chain Ordering Extended Community 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.¶

The Community attribute [I-D.ietf-idr-wide-bgp-communities] describes an attribute with flexible format for specifying community information. The flexible format defines a short common header followed by type-specific community. FSv2 [I-D.ietf-idr-flowspec-v2] defines a new type of Community denoted as a FSv2 Action for the Community Attribute (FSv2-CA) This FSv2 More IP Actions [I-D.hares-idr-fsv2-more-ip-actions]) defines the format of the FSv2-CA.¶

  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-5

Table 3-3 Generic Transitive Extended Community
          Part 1 - (0x80)

IPv4 Extended Communities (Type 0x80)
Value   Description                    Name   Reference
=====   =======================        =====  ==========
0x01    FSv2 Action Chain Ordering     ACO    [This document]
0x06    FSv2 traffic-rate-byte         TRB    [RFC8955]
0x07    Flow spec traffic-action       TAIS   [RFC8955]
0x08    Flow spec rt-redirect          RDIP   [RFC8955]
        AS-2 octet format
0x09    Flow spec Remark DSCP          TMDS   [RFC8955]
0x0C    Flow Spec Traffic-rate-packets TRP    [RFC8955]
0xOD    Flow Spec for SFC classifiers  SFCC   [RFC9015]

Table 3-4 Generic Transitive Extended Community
          Part 2 (0x81)

IPv4 Extended Communities FSv2 action (Type 0x81)
Value   Description                  Name  Reference
=====   =======================      ===== ==========
0x08    Flow spec rt-redirect        RDIP  [RFC8955]

Table 3-5 Generic Transitive Extended Community
                  Part 3 (Type 0x82)

Value   Description                  Name  Reference
=====   =======================      ====  ==========
0x08    Flow spec rt-redirect        RDIP  [RFC8955]
        AS-4 octet format

Table 3-6: Traffic Action bits

Bit     Name                Name  Reference
=====   ===============     ====  ==========
 47          Terminal Action    TAct  [RFC8955]
 46      Sample             Samp  [RFC8955]
 45      Copy               Copy  [this document]
 44      Drop               drop  [this document]

              Figure 3-13

Table 3-7 Transitive Extended Community types (T-EC-types)

sub-type   FSv1 Description                Name
========   ==================              ====
0x07       FS Interface set                Ifset
0x08       FS Redirect/Mirror              RIPv4
0x09       FS Redirect to Indirection ID   RGID

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type         |  Sub-type     |   Global Administrator        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 |         Global Administrator (cont.)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Global Administrator (cont.)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Global Administrator (cont.)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Global Administrator (cont.)  |   Local Administrator         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3-6

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-8 transitive IPv6-Address-Specific Actions
Value   Description                         Name
=====   =======================             =====
0x01    Flow Spec Action Chain              ACO
0x0C    Flow Spec redirect-v6-flag          RD6F
0x0D    Flow Spec rt-redirect IPv6 format   RDv6
        IPv6 format

Table 3-9: Conflicts between FSv2 Transitive Generic IPv4 actions

IPv4 Extended Communities (Type 0x80)
Value   Name  Conflicts with
=====   ===== ========================
0x01    ACO   none
0x06    TRB   TRP
0x07    TAIS  duplication also done in
              RDIP, RIPv4, RGID
0x08    RDIP  redirection done in
              RIPv4, RGID
              copy done in TAIS
0x09    TMDS  none
0x0C    TRP   TRB
0xOD    SFCC  none

Table 3-10 Transitive IPv6-Address-Specific Actions
Value   Name   Conflicts with
=====   ====== =================
0x01    ACO    none
0x0C    RD6F   RDv6
0x0D    RDv6   RD6F

Table 3-11 Default Order of FSv2-EC IPv4 Actions

IPv4 Extended Communities (Type 0x80)
Value   Description                    Name
=====   =======================        =====
0x01    FSv2 Action Chain Ordering     ACO
0x06    FSv2 traffic-rate-byte         TRB
0x07    Flow spec traffic-action       TAIS
0x07    FS Interface set
0x08    Flow spec rt-redirect          RDIP
0x08    FS Redirect/Mirror             RDIPv4
0x08    FS Redirect/Mirror             RDIPv4
0x09    FS Redirect to Path ID         RD
0x09    Flow spec Remark DSCP          TMDS
0x0C    Flow Spec Traffic-rate-packets TRP
0xOD    Flow Spec for SFC classifiers  SFCC

Note: If FS Interface is widely deployed
it would be good to move it to another
type.

Table 3-12 default order for FSv2-EC IPv6 actions
Value   Name   Conflicts with
=====   ====== =================
0x01    ACO    none
0x0C    RD6F   RDv6
0x0D    RDv6   RD6F

   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(01) |ACO-dependency |  AC-Failure   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          AC-Failure-value (cont.)                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3-7

   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(07) |traffic action field  (zero)   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          AC-Failure-value (cont.)                   |ACF|I|S|T|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3-8

 Where
 ACO - is the Action Chain failure types (0x00 to 0x03)
       00 - stop on failure
           01 - continue on failure
           02 - conditional stop on failure (by policy)
           03 - rollback on failure (with policy)
 I - Implementation ordering and interaction
      0 - Default FSv2 ordering and interation
          1 - Implementation defined user
 S - Sample flag
 T - Terminal action

Table 3-13 - All FSv2 IPv4 Action types for IP DDOS

 Action  Name  Description             May Interacts
 ======  ====  ======================  ===============
   01    ACO   Action Chain Operation  none
   06    TRB   Traffic Rate limited    TRP
                by Bytes
   07    TA    Traffic Action          none
               (terminal/sample/ACO)
   08    RDIP  Redirect IPv4           none
   09    TM    Mark DSCP value         none
   12    TRP   Traffic Rate limited    TRB
                by Packets

Table 3-14 – All FSv2 IPv6 Action types for IP DDOS

 Action  Name  Description             May Interacts
 ======  ====  ======================  ===============
   01    ACO   Action Chain Operation  none
   06    TRB   Traffic Rate limited    TRP
                by Bytes
   07    TA    Traffic Action          none
               (terminal/sample/ACO)
   08    RDIP  Redirect IPv4           none
   09    TM    Mark DSCP value         none
   12    TRP   Traffic Rate limited    TRB
                by Packets

Table 3-15 -  All IP Actions in Extended Communities

 Action   Name: Description
 ======   ===========
   00     reserved
   01     ACO:  action chain operation
   02     reserved
   03     TAIS: traffic actions per interface group
   04     LkBW: Link bandwidth
          (draft-ietf-idr-linkbandwidth-07) [non-transitive]
                  [juniper link bandwidth] [transitive]

   06     TRB:  traffic rate limited by bytes
   07     TA: traffic action (terminal/sample)
   08     RDIP: Redirect IPv4
   09     TM: mark DSCP value
   10     TBA (to be assigned)
   11     TBA (to be assigned)
   12     TRP: traffic rate limited by packets
   13     TISFC: SFC Classifier
   14     RDIID: redirect to Indirection-id (move from 0x00)

   31     TISFC: SFC classifier II (this document)
   32     MPLSLA: MPLS label action
   33     VLAN: VLAN-Action (0x16)[draft-ietf-idr-flowspec-l2vpn-17]
   34     TPID: TPID-Action (0x17)[draft-ietf-idr-flowspec-l2vpn-17]
   24-254 TBA (to be assigned)
   255    reserved

 Table 3-16 IPv6 Extended Communities (Type 1)

Value   Description                  Name   Reference
=====   =======================      =====  ==========
0x01    Flow Spec Action Chain       ACO    [This document]
0x0C    Flow Spec redirect-v6-flag   RD6F   [ID-redirect-IP]
0x0D    Flow Spec rt-redirect        RD6    [RFC8956]
        IPv6 format

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], 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].¶

4.2. Ordering for Flow Specification v2 (FSv2)

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 7.0 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.¶

4.3. Ordering of FS filters for BGP Peers 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.¶

Example 3: Mixed Flow Specification Support -¶

• Suppose an FSv2 peer (BGP Peer A) has the capability to send either FSv1 or FSv2. BGP Peer A peers with BGP Peers B, C, D and E.¶

• BGP Peer B can only send FSv1 routes (NLRI + Extended Community). BGP Peer C can send FSv2 routes (NLRI + path attributes (wide community or extended community or none)). BGP Peer D cannot send any FS routes. BGP E can send FSv2 and FSv1 routes¶

• BGP Peer A sends FSv1 routes in its databases to BGP B. Since the FSv2 NLRI cannot be sent to the FSv1 peer, only the FSv1 NLRI is sent. BGP Peer A sends to BGP C the FSv2 routes in its database (configured or received).¶

• BGP peer A would not send the FSv1 NLRI or FSv2 NLRI to BGP Peer D. The BGP Peer D does not support for these NLRI.¶

• BGP Peer A sends the NLRI for both FSv1 and FSv2 to BGP Peer E.¶

      +---------+                       +---------+
      |    A    |=======================|    C    |
      |FSv1+FSv2|.                   . .|  FSv2   |
      +---------+ .                 .   +---------+
       ||  |   \   .               .      .     ||
       ||  |    \   . . . . . . . . .     .     ||
       ||  |     \               .   .    .     ||
       ||  |      \-----\      .      .   .     ||
       ||  |             \    .        .  .     ||
      +---------+       +------+       +-----+  ||
      |    E    |-------|  B   |. . . .|  D  |  ||
      |FSv1+FSv2|       | FSv1 |       |no FS|  ||
      +---------+       +------+       +-----+  ||
        ||     .                         .      ||
        ||     . . . . . . . . . . . . . .      ||
        ||                                      ||
        |========================================|

        Double line = FSv2
        Single line = FSv1
        Dotted line = BGP peering with no FlowSpec

         Figure 4-1: FSv1 and FVs2 Peering

6.1. 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.¶

6.2. 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.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-00, 8 May 2024, <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-more-ip-actions-00>.

[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-00, 3 May 2024, <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-more-ip-filters-00>.

[I-D.ietf-idr-bgp-flowspec-label]

liangqiandeng, Hares, S., You, J., Raszuk, R., and D. Ma, "Carrying Label Information for BGP FlowSpec", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec-label-02, 20 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-flowspec-label-02>.

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

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

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

Weiguo, H., Eastlake, D. E., Litkowski, S., and S. Zhuang, "BGP Dissemination of L2 Flow Specification Rules", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-l2vpn-23, 15 April 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-23>.

[I-D.ietf-idr-flowspec-mpls-match]

Yong, L., Hares, S., liangqiandeng, and J. You, "BGP Flow Specification Filter for MPLS Label", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-mpls-match-02, 20 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-mpls-match-02>.

[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-19, 26 December 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-19>.

[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]

Uttaro, J., Haas, J., Texier, M., akarch@cisco.com, Ray, S., Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to IP Action", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-02, 5 February 2015, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-02>.

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

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

[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-11, 9 March 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-wide-bgp-communities-11>.

[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>.

[RFC3032]

Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, <https://www.rfc-editor.org/info/rfc3032>.

[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>.

[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>.

[RFC6482]

Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.

[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>.

9.2. Informative References

[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>.

[RFC8300]

Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.