BGP Flow Specification Version 2

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. Flow Specification v2 (FSv2) Overview

Flow Specification v2 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.¶

This FSv2 specification 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].¶

The FSv2 specification for tunnel traffic is outside the scope of this specification. The FSv1 specification for tunneled traffic is in [I-D.ietf-idr-flowspec-nvo3]. The FSv2 tunnel traffic will be defined in [FSv2-Tunnel].¶

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 Wide Communities. Only Wide Communities can associate a user-defined order for the actions. Extended Community actions occur after actions with a user specified order (see section 5.2 for details).¶

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

       +--------------------------------+
       |          Rule Group            |
       +--------------------------------+
         ^          ^                  ^
         |          |---------         |
         |                   |         ------
         |                   |               |
+--------^-------+   +-------^-----+     +---^-----+
|      Rule1     |   |     Rule2   | ... |  Rule-n |
+----------------+   +-------------+     +---------+
                      :  :   :    :
    :.................:  :   :    :
    :          |.........:   :    :
 +--V--+    +--V--+          :    :
 | name|    |order| .........:    :.....
 +-----+    +-----+ :                  :
                    :                  :
   +----------------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 DDOS, IPv4/IPv6 filters beyond DDOS, BGP/MPLS IPv4 VPN, BGP/MPLS IPv6 VPN, BGP/MPLS L2VPN, Segment routing (SRMPLS, SRv6), SFC, SFC VPN, and tunnel.¶

The following is the list of planned drafts:¶

FSv2 IP DDOS (FSv2 IP DDOS):

The first draft will support IP filter functions (Type 1) and Extended Community actions supported by [RFC8955] and [RFC8956] with additions to provide the following:¶

• user ordering of IP filters¶

• new filter for filtering of unknown FSv2 types and filters (type = 250)¶

• no support for user ordering of actions¶

• a new action (Action Chain Operation) for handling failures when multiple actions are associated with a set of filters.¶

This draft provides the basic functions all other FSv2 drafts will extend.¶

FSv2 IP Extensions (FSv2 IP DDOS Extra):

This draft provides extensions for proposed filters for IP FSv2.¶

FSv2 Non-IP (FSv2 Non-IP):

This draft provides Non-IP Filters filters for BGP/MPLS IPv4 VPNS, BGP/MPLS IPv6 VPNs, Segment Routing (SRMPLS and SRV6).¶

FSv2 L2VPN:

[I-D.ietf-idr-flowspec-l2vpn] provides user ordered filters for L2VPNs.¶

FSv2 Additional Extended Community Actions (FSv2 EC Actions Extra) :

This draft provides additional Flow Specification Actions that can be implemented safely with action chain failures, but without user ordering.¶

FSv2 Wide Community Actions in Type 1 (FSv2 Wide Action T1):

This draft provides the Wide Community actions in the Type 1 format of Wide communities.¶

FSv2 Wide Community Actions in Type 2 (FSv2 Wide Action T2):

This draft provides Wide Community actions in the type 2 format of Wide communities.¶

3.1. Basic IP Filters

    +-------------------------------+
    | +--------------------------+  |
    | | (subTLVs)+               |  |
    | +==========================+  |
    +-------------------------------+

      Figure 3-2 - IP Header TLV

    +-------------------------------+
    |  SubTLV type (1 octet)        |
    +-------------------------------+
    |  length (1 octet)             |
    + ------------------------------+
    |  value (variable)             |
    +-------------------------------+
     Figure 3-3 – IP header SubTLV format

Table 2 IP SubTLV Types for IP Filters
        DDOS support
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)

Table 2b 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

          0   1   2   3   4   5   6   7   8       9      10  11  12  13  14  15
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |            T-Err              |  M-error                      |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
                 Figure 3-8b

3.2. Encoding of FSV2 Actions for Basic DDOS

The long-term goal of the FSv2 actions is to allow user ordering of the flow specification actions. Only Wide Communities provide enough structured space for user ordering of actions. The IDR WG draft [I-D.ietf-idr-flowspec-v2] contains the long-term plan for FSv2 filters with actions. To provide an easy migration between FSv1 and FSv2, a sequence of drafts will break allow adding of additional actions to the basic IP DDOS actions in the Extended Community.¶

The Basic IP DDOS FSv2 will support existing IPv4 from [RFC8955], and existing IPv6 actions from [RFC8956] and one additional feature for action chain ordering (ACO).¶

An action chain for FSv2 Extended Community actions is defined as a series of Extended Communities which are attached to a set of filters.¶

The action chain ordering (ACO)action provides a set of flags that define a clear action if failure occurs. One of the issues with FSv1 is the lack of a clear definition on what happens if multiple actions interact. The existance of the Action chain ordering action enforces that the actions will have a deterministic outcome during failures.¶

The AC-Failure types are:¶

• 0x00 – default – stop on failure¶

• 0x01 – continue on failure (best effort on actions)¶

• 0x02 – conditional stop on failure (depends on AC-Failure-value/policy)¶

• 0x03 – rollback do all or nothing (depends on AC-Failure-value/policy)¶

Editors note: The following options for encoding ACO exist.¶

Option 1:

redefine bits in Traffic Action subtype¶

Option 2:

create a new Extended Community¶

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type high    |  Type low(*)  |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value (6 octets)     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              Figure 3-9

                                Table x-x

IPv4 Extended Communities (Type 0x80) 2 byte AS,
Value   Description                    Name  Reference
=====   =======================        ===== ==========
0x01    Flow Spec Action Chain         ACO   [This document]
0x06    Flow spec 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 traffic-remarking        TM    [RFC8955]
0x0C    Flow Spec Traffic-rate-packets TRP   [RFC8955]

                                Table x-x

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

                                Table x-x
IPv4 Extended Communities (Type 0x82)
Value   Description                  Name  Reference
=====   =======================      ====  ==========
0x08    Flow spec rt-redirect        RDIP  [RFC8955]
        AS-4 octet format

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

The 20 octets of value are given in the following format:

Type = 0x00 (transitive)
Sub-Type = see table x-x

Global Administrator: IPv6 address assigned by Internet Registry
Local Administrator:  2 bytes of

Table x-x

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

   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) |AC-failure-type|  AC-Failure   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |          AC-Failure-value (cont.)                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.)                   | ACO |S|T|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 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)
 S - Sample flag
 T - Terminal action

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

          Figure 3-15

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

          Figure 3-15

 Table 4  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

          Figure 3-15

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

FS Action                          Value Order
(lowest value to highest)          (lowest to highest)
================================   ==============================
0x01: ACO: Action chain operation  Failure flag
0x02: TAIS:Traffic actions per     AS, then Group-ID, then Action ID
       Interface group

0x03-0x05 to be assigned           TBD
0x06: TRB: Traffic rate limit      AS, then float value
      by bytes
0x07: TA: Traffic Action           traffic action value
0x08: RDIP: Redirect to IP             AS, then IP Address, then ID
0x09: TM: Traffic Marking          DSCP value (lowest to highest)
0x0A: AL2: Associated L2 Info.     TBD
0x0B: AET: Associated E-tree Info. TBD
0x0C: TRP: Traffic Rate limit      AS, then float value
         by bytes
0x0D: RDIPv6: Traffic
        Redirect to IPv6           AS, IPv6 value, then local Admin
0x0E: TISFC: Traffic insertion
     to SFC                        SPI, then SI, the SFT
0xOF: Redirect to
          Indirection-ID           ID-type, then Generalized-ID

0x10: MPLSLA: MPLS Label stack     order, action, label, Exp
0x16 – VLAN action                 rewrite-actions, VALN1, VLAN2,
                                   PCP-DE1, PCP-DE2
0x17 – TPID action                 rewrite actions, TP-ID-1, TP-ID-2

                 Figure 6-1

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 6-2: 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.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-22, 16 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-22>.

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

[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-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-04, 8 October 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-srv6-04>.

[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-02, 21 May 2023, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-v2-02>.

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