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

This FSv2 specification supports the components and actions for the following:¶

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

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

• L2 (AFI=6, SAFI=TDB1),¶

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

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

• BGP/MPLS L2VPN (AFI=25, SAFI=TDB2),¶

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

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

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

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

3.1. 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
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 (Differentiated Services Code Point)
  12 –  Fragment
  13 –  Flow Label
  14 -  TTL
  15-63 unassigned (IP flow)

 Table 3 Non-IP Types for IP Filters
SubTLV
-type     Definition
======    ============
  64 –    Parts of SID
  65 -    MPLS Match 1: Label in Label stack
  66 -    MPLS Match 2: EXP bits in top Label
  67-249  unassigned (reserved for now)
  250-    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
    +---+---+---+---+---+---+---+---+
    | e | a | field type|lt |gt |eq |
    +---+---+---+---+---+---+---+---+
            Figure 3-5

         Table 3 - SID Parts fields

       +-----------------------+------------------------------+
       | Field Type            | Value                        |
       +=======================+==============================+
       | SID's LOC             | value of LOC bits            |
       +-----------------------+------------------------------+
       | SID's FUNCT           | value of FUNCT bits          |
       +-----------------------+------------------------------+
       | SID's ARG             | value of ARG bits            |
       +-----------------------+------------------------------+
       | SID's LOC:FUNCT       | value of LOC:FUNCT bits      |
       +-----------------------+------------------------------+
       | SID's FUNCT:ARG       | value of FUNCT:ARG bits      |
       +-----------------------+------------------------------+
       | SID's LOC:FUNCT:ARG   | value of LOC:FUNCT:ARG bits  |
       +-----------------------+------------------------------+

        ------------------ SID,  128 bits ----------------
       /                                                  \
      +-----------+-----------+-----------+----------------+
      |    LOC    |   FUNCT   |    ARG    |      ...       |
      +-----------+-----------+-----------+----------------+
       \         / \         / \         / \              /
          j bits     k bits       m bits    128-j-k-m bits
       \                     /
         LOC:FUNCT, j+k bits
                   \                     /
                     FUNCT:ARG, k+m bits
       \                                 /
         -- LOC:FUNCT:ARG, j+k+m bits –

                              Figure 3-6

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

       +-------------------------------+
       | +--------------------------+  |
       | | AFI/SAFI field (3)       |  |
       | +--------------------------+  |
       | | L3 AFI (2)               |  |
       | +--------------------------+  |
       | | L2 filter length (2)     |  |
       | +--------------------------+  |
       | | (SubTLVs)+ (L2 then L3)  |  |
       | +--------------------------+  |
       +-------------------------------+
         Figure 3-10 -L2 Header TLV value

        Each SubTLV has the format:

    +-------------------------------+
    |  SubTLV type (1 octet)        |
    +-------------------------------+
    |  length (1 octet)             |
    + ------------------------------+
    |  value (variable)             |
    +-------------------------------+
             Figure 3-11

Component Types Table

Component
type      Description
=======   ==================
1          EtherType
2          Source MAC
3          Destination MAC
4          DSAP (destination service access point)
5          SSAP (source service access point)
6          control field in LLC
7          SNAP
8          VLAN ID
9          VPAN PCP
10         Inner VLAN ID
11         Inner VLAN PCP
12         VLAN DEI
13         VLAN DEI
14         Source MAC special bits
15         Destination MAC special bits

   Table 4 – L2 VPN components

    +--------------------------------------+
    | +---------------------------------+  |
    | | Tunneled AFI/SAFI field         |  |
    | +---------------------------------+  |
    | |                                 |  |
    | | <subTLVs>+                      |  |
    | +---------------------------------+  |
    +--------------------------------------+

              Figure 3-12

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

   1 = SFIR RD Type (types 1, 2, 3)
   2 = SFIR RD Value
   3 = SFIR Pool ID
   4 = SFIR MPLS context/label
   5 = SFPR SPI
   6 = SPF attribute fields

    Table 5 – SFC Filter types

       +-------------------------------+
       | +--------------------------+  |
       | | AFI/SAFI field (3)       |  |
       | +--------------------------+  |
       | | Route Distinguisher (8)  |  |
       | +--------------------------+  |
       | | (subTLVs)+               |  |
       | +--------------------------+  |
       +-------------------------------+

         Figure 3-14: VPN IP Filter Header

       +-------------------------------+
       | +--------------------------+  |
       | | AFI/SAFI field (3)       |  |
       | +--------------------------+  |
       | | Route Distinguisher (8)  |  |
       | +--------------------------+  |
       | | L3 AFI (2)               |  |
       | +--------------------------+  |
       | | L2 filter length (2)     |  |
       | +--------------------------+  |
       | | (subTLVs)+               |  |
       | +--------------------------+  |
       +-------------------------------+

         Figure 3-15: VPN L2 Filter Header

3.2. FSV2 Actions

The FSv2 actions may be sent in an Extended Community or a Wide Community. User ordering of FSv2 actions requires using Wide Communities.¶

The Extended Community encodes the Flow Specification actions in the Extended IPv4 Community format [RFC4360] or in the extended IPv6 Community format [RFC5701]. The Extended Community actions cannot be ordered by the user. The implementer and the network deploying these actions need to ensure that policy constraints these Extended Community actions appropriately. A new Extended Community (Action Chain Order) is defined below to provide a clear failure mode for FSv2 actions implementation that support this action.¶

Implementation for a basic DDOS should include FSv2 IP filters, Extended Community actions, and the new Action Chain Ordering (This grouping of FSv2 features will be denoted as FSv2 Basic IP DDOS).¶

Wide Community can support user ordering of actions, and the dependency between actions. Wide Communities allow for multiple types of formats by supporting a common header with type and an indication whether the type is transitive within ASes or Confederations. The only Type 1 defined by the [I-D.ietf-idr-wide-bgp-communities] or a new Type 2 Wide Community (this document). The Type 1 body is a general community header that contains 31 bits of a community (4 bytes), a source AS (4 octets), and a context AS, and TLVs.¶

This specification defines a type 2 format Wide Communities that is specific to Flow Specification Actions. For new implementations, this form is streamline for FSv2 actions. A Wide Community Type 1 format is provided to ease transition, but it may contain extra bytes unneeded by FSV2 actions.¶

This section first describes the following Information related to FSv2 Actions in Extended Communities:¶

• IPv4 Extended Community formats for FSv2 Actions¶

• IPv6 Extended Community formats for FSv2 actions¶

• Action Chain Ordering IPv4 Extended Community¶

• interaction issues between FSv2 Extended Community formats.¶

Second this section describes the information regarding user-ordered FSv2 actions encoded in Wide Communities:¶

• Encoding of FSv2 actions TLVs in Type 2 Wide Community¶

• Encoding of FSv2 action TLVS in Type 1 Wide Community>¶

• FSv2 Action TLVs for Wide Community¶

• User Ordering of only FSv2 Wide Community actions¶

• User Ordering of Wide Community and Extended Community actions¶

  IPV4 Extended Community 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(*)  |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          Value (6 octets)     |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3-16

                                Table 6

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][This document]
0x07    Flow spec traffic-action     TAIS  [RFC8955][This document]
0x08    Flow spec rt-redirect        RDIP  [RFC8955][This document]
        AS-2 octet format
0x09    Flow spec traffic-remarking      TM    [RFC8955][this document]
0x0C    Flow Spec Traffic-           TRP   [RFC8955][this document]
         rate-packets

                                Table 7

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

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

 IPv6 Extended Community 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-17

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

Global Administrator - IPv6 Address setting extended community
Local Administrator - 2 bytes of Community for action.

                 Table 9

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

  Wide Community common header

   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              |    Flags  |T|C|   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |    Type 1 or Type 2 format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+............................

                          figure 3-18

where:

Type = the type of community (Type 1 or Type 2)
Flag = include an octet of bits with only two
       bit that can be set
           T = 1 - Transitive across AS boundaries
           T = 0 - Non-Transitive across AS boundaries
           C = 1 - Transitive across Confederation boundaries
           C = 0 - Non-Transitive across Confederation boundaries

Common header with Type 2 specified

 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=2           |    Flags  |C|T|   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |<sequence of FSv2-Action-TLV>+ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3-19

Type 1 Wide 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| user Action order           | dependency chain ID           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Source AS Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Context AS Number                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       <action-subTLVs>                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3-20

 action order -    2 octets with user ordering within the list
                   1 octet has high bit set to zero (0).
                                   This allows values
                   with values from  1 (0x01) to 32752 (0xFF00)
                   ascending ordering (1 (first) to 65280.

 D-chain (Dependency chain) -  1 octet with dependency chain ID
 D-chain order (D-chain order) -  1 octet with order within chain

 Action Sub-TLVs - variable length format
                   see definitions within this document.

     0  1  2  3  4  5  6  7
   +--+--+--+--+--+--+--+--+
   |R |R |   DSCP bits     |
   +--+--+--+--+--+--+--+--+

        Figure 3-21

[Flags (1 octet)] [ID-Type (1 octet)][Generalized-ID (4 octets)]

     Figure 3-22

+------+------------------------------------------------------------+
|Action| Function                                                   |
+------+------------------------------------------------------------+
|  0   | Push the MPLS tag                                          |
+------+------------------------------------------------------------+
|  1   | Pop the outermost MPLS tag in the packet                   |
+------+------------------------------------------------------------+
|  2   | Swap the MPLS tag with the outermost MPLS tag in the packet|
+------+------------------------------------------------------------+
| 3~15 | Reserved                                                   |
+------+------------------------------------------------------------+

                    Figure 3-23

  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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                Label                  | Exp |S|       TTL     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3-24 - Label Stack Entry

     0   1   2   3   4   5   6   7   8   9   10  11  12  13  14  15
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |PO1|PU1|SW1|RI1|RO1| Resv      |PO2|PU2|SW2|RI2|RO2| Resv      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                           Figure 3-25

        0                                           15
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
      |TI|TO|                     Resv                |
      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

                Figure 3-26

                        Table 10

Sub-TLV  Action Action SubTLV      Extended Community
type     Name   format             format
=======  =====  ===============    ====================
 1       ACO    type: 1 (0x01)      IPv4 type (0x01)
                length:variable     length: 6
                                                    [2-octet-AS]

 2       TAIS   type: 2 (0x02)      type: 0x0702 or 0x4702
                length:8            length: 6
                [4-octet-as]         [4-octet-AS]
                [group-3-octet]      [flags-group]
                [flags-1-octet]        (2 octets)

 3-5     reserved



Sub-TLV Action Action SubTLV      Extended Community
type    Name   format             format
======= =====  ===============    ====================
 6       TRB    type:6 (0x06)       type:8006
                length:8            length: 6 octets
                [4-byte-AS]          [2-byte-AS]
                [float (4 octets)]   [float (4 octets)]

 7       TA     type:7              type:8007
                length:1            length:6 octets
                flags: (1 octet)    flags (6 octets)


 8       RDIPv4 type:8              type:8008
                length: 12          length: 6 octets
                [4-byte-AS]          [AS-2-octets]
                [IPv4-address]       [IPv4 address]
                                    type:8108
                                    length: 6 octets
                                     [IPv4 address]
                                     [ID-2 octets]
                                    type:8208
                                    length: 6 octets
                                     [AS-4-octets]
                                     [ID-2-octets]

9       TM      type:9              type:8009
                length:1            length: 6 octets
                DSCP: 1 octet        DSCP: 1 octet

10-11           Unassigned

12      TRP     type:12 (0x0C)     type: 0x800C
                length: 8 octets   length: 6 octets
                [4-byte-AS]         [2-byte-AS]
                [float-4-octet]     [float-4-octet]

13      RDIPv6  type:13 (0x0D)     type:0x000D (IPv6)
                length:22          length: 18 octets
                [4-byte-AS]         [IPv6-address (16)]
                [IPv6-address (16)] [local-admin (2)]
                [local-admin (2)]


15      RDIID   type:15 (0x0F)      type: 0900 (FSv1)
                length: 6           length 6
                flags (1)            flags (1)
                ID-type (1)          ID type (1)
                G-ID (4 octets)      G-ID (4-octets)

             Table 11

Non-IP packet actions
Sub-TLV Action Action SubTLV      Extended Community
type    Name   format             format
======= =====  ===============    ====================

33      TISFC   type:33 (0x21)      type: 0xD (FSv1/FSv2)
                length:6            length:6
                SPI (3 octets)       SPI (3 octets)
                SI (1 octet)         SI (1 octet)
                SFT (2 octets)       SFT (2 octets)

34      MPLSLA  type:34 (0x10)       (TBD)
                length: 6
                                action: 1 octet
                                [push/pop]
                                order: 1 octet
                mpls label (4 octets)



35      VLAN    type:35 (0x22)      Type: (TBD)
                length:6            length:6
                [rewrite-action(2)]  [rewrite-actions (2)]
                [vlan-pcp-de-1 (2)]  [vlan-pcp-de-1 (2)]
                [vlan-pcp-de-2 (2)]      [vlan-pcp-de-2 (2)]

36      TPID    type:35 (0x23)      Type: (TBD)
                length:6            length:6
                [rewrite-action(2)] [rewrite-actions (2)]
                [TP-ID-1 (2)]       [TP-ID-1 (2)]
                [TP-ID-2 (2)]       [TP-ID-2 (2)]

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

• Flow specification routes (FSv1 or FSv2) received over SAFI=133 will be validated against SAFI=1,¶

• Flow Specification routes (FSv1 or FSv2) received over SAFI=134 will be validated against SAFI=128, and¶

• Flow Specification routes (FSv1 or FSv2) [AFI =1, 2] received over SAFI=77 will be validated using only the Outer Flow Spec against SAFI = 133.¶

The FSv2 validates L2 FSv2 NLRI with the following L2 routes received over the same AFI (25), but a different SAFI:¶

• Flow specification routes (FSv1 or FSv2)received over SAFI=135 are validated against 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-math 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.¶

4.2. Validation of Flow Specification Actions

Flow Specifications may be mapped to actions using Extended Communities or a Wide Communities. The FSv2 actions in Extended Communities and Wide communities can be associated with large number of NLRIs.¶

The ordering of precedence for these actions in the case when the user-defined order is the same follows the precedence of the FSv2 NLRI action TLV values (lowest to highest). User-defined order is the same when the order value for action is the same. All Extended Community actions MUST be translated to the user-defined order data format for internal comparison. By default, all Extended Community actions SHOULD be translated to a single value.¶

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 (RDIPv4, RDIPv6, RDIID, ) Each FSv2 actions in this document defines the potential conflicts or duplications. Specifications for new FSv2 actions outside of this specification MUST specify interactions or conflicts with any FSv2 actions (that appear in this specification or subsequent specifications).¶

Well-formed syntactically correct actions should be linked to a filtering rule in the order the actions should be taken. If one action in the ordered list fails, the default procedure is for the action process for this rule to stop and flag the error via system management. By explicit configuration, the action processing may continue after errors.¶

Implementations MAY wish to log the actions taken by FS actions (FSv1 or FSv2).¶

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

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

5.2. Ordering of the Actions

The FSv2 specification allows for actions to be associated by:¶

• a) a Wide Community path attribute, or¶

• b) an Extended Community path attribute.¶

Actions may be ordered by user-defined action order number from 1-n (where n is 2**16-2 and the value 2**16-1 is reserved.¶

Byy default, extended community actions are associated with default order number 32768 [0x8000] or a specific configured value for the FSv2 domain.¶

Action user-order number zero is defined to have an Action type of “Set Action Chain operation” (ACO) (value 0x01) that defines the default action chain process. For details on “set action chain operation” see section 3.2.1 or section 5.2.1 below.¶

If the user-defined action number for two actions are the same, then the actions are ordered by FSv2 action types (see Table 3 for a list of action types). If the user-defined action number and the FSv2 action types are the same, then the order must be defined by the FSv2 action.¶

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

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

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

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

11.2. Informative References

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