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  |
       | AFI/SAFI 1/133,     |    | Communities      |
       | 1/134, 2/133, 2/134 |    |                  |
       +-------------------+      +------------------+
           :     :    :                 :      :    :
      .....:     .    :.....       .....:      .    :.....
      :          :         :       :           :         :
 +----V---+  +---V----+ +--V---+ +-V------+ +--V-----++--V---+
 |  Match |  | match  | |match | | Action | | action ||action|
 |Operator|  |Variable| |Value | |Operator| |variable|| Value|
 |*1      |  |        | |      | |(subtype| |        ||      |
 +--------+  +--------+ +------+ +--------+ +--------++------+

   *1 match operator may be complex.

   Figure 2-1: BGP Flow Specification v1 Policy

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),¶

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

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

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

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

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

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

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

The IDR specification for L2 VPN traffic was specified in [I-D.ietf-idr-flowspec-l2vpn]. An IDR specification for tunneled traffic is in [I-D.ietf-idr-flowspec-nvo3]. Both of these drafts were targeted for FSv1, but the WG decided to implement these as FSv2. The series of FSv2 support the same scope of functionality in a series of documents.¶

FSv2 operates in the ships-in-the night model with FSv1 so network operators can manipulate which the distribution of FSv2 and FSv1 using configuration parameters. Since the lack of deterministic ordering was an FSv1 problem, this specification provides rules and protocol features to keep filters in a deterministic order between FSv1 and FSv2.¶

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

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

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

  • The user-specified order is carried in the FSv2 NLRI and a numerical lower value takes precedence over a numerically higher value. For rules received with the same order value, the FSv1 rules apply (order by component type and then by value of the components).¶

• 3) FSv2 rules are added starting with Rule 1 and FSv1 rules are added after FSv2 rules¶

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

• 4) An FSv2 peer may receive BGP NLRI routes from a FSv1 peer or a BGP peer that does not support FSv1 or FSv2. The capabilities sent by a BGP peer indicate whether the AFI/SAFI can be received (FSv1 NLRI or FSv2 NLRI).¶

• 5) Associate a chain of actions to rules based on user-defined action number (1-n). (optional)¶

  • If no actions are associated with a filter rule, the default is to drop traffic the filter rules match¶

  • An action chain of 1-n actions can be associated with a set of filter rules can via Extended Communities or a Community Path attribute with a FSv2 type. Only the Community attribute allows for user-defined order for the actions. If an implementation allows for FSv2 actions with user-ordering and Extended Community actions, the by default the Extended Community are ordered after the user-ordered actions. This FSv2 action order default can be changed by the Action Chain Ordering FSv2 action. Currently, there is no FSv2 definition for an action dependency chain, but space has been left in the BGP Community Path attribute format for development of action dependency mechanisms.¶

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

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

   Figure 2-2: BGP FSv2 Data storage

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

  Figure 3-1 - NLRI format

where:¶

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

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

Each each TLV has the Format:¶

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

 Figure 3-2 - TLV format within FSv2 NLRI

where:¶

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

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

  Why needed in FSv2:

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

  For basic FSV2:

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

  For future FSV2:

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

• FSv2 Filter type: contains a type for FSv2 TLV format of the NRLI (2 octets) which can be:¶

  • 0 - reserved,¶

  • 1 - IP Basic Filter Rules¶

  • 2 - Extended IP Filter rules¶

  • 3 - MPLS Traffic Rules¶

  • 4 - L2 traffic rules¶

  • 5- SFC Traffic rules¶

  • 6 - Tunneled traffic¶

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

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

All FSv2 function must recognize valid Filter Types, even if the handling of the Filter types are not supported by the implementation. The TLV allows all FSv2 Filter types to be passed, even if the Filter rules cannot be installed.¶

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

3.2. FSv2 Basic IP Filters

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

        Figure 3-3: Numeric Operator (numeric_op)

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

               Table 3-1: Comparison Operation Combinations

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

    Figure 3-4 Bitmask Operator (bitmask_op)

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

Figure 3-5 NLRI format for FSv2 IP Filter Type

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

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

  14-63   Reserved for IP Filter Extensions
  64-150  Reserved for Non-IP Filters
          (L2, MPLS, tunnel) - STD action
 151-191  Reserved for Associated Data
 192-249  FCFS
 250-255  Reserved

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

3.3. FSv2 Actions for FSv2 IP Basic

The IP Basic FSv2 allows FSv2 actions to be sent in an Extended Community (FSv2-EC) for IPv4 and IPv6. The Extended Community encodes the Flow Specification actions in the Extended IPv4 Community format [RFC4360] or in the extended IPv6 Community format [RFC5701]. The FSv2-EC actions cannot be ordered by the user and some FSv2-EC interaction cause conflicting actions.¶

This section defines the FSv2-EC actions as FSv1 actions plus one additional action (Action Chain Ordering). This setion reviews the existing FSv2-EC action formats (section 3.3.1), the interaction between existing FS-EC actions (section 3.3.2), and the FSv2 default order of actions (section 3.2.3). For those familar with the FSv1 actions, Tables 3-7 and 3-8 in section 3.3.3 have the default order for FSv2-EC actions.¶

Section 3.4 defines Action Chain Ordering (ACO) FSv2-EC. The ACO FSv2-EC provides two actions. The first action signals if implementation specific ordering of FS-EC actions replaces the default FSv2 ordering. The second is handles an a ction failiure if multiple actions are attached to a filter match. If there are multiple actions are attached in a chain, the first action could fail. The ACO FSv2-EC aids the transition between FSv1 actions which are ordered uniquely by each implementation, and the FSv2 actions which use a global default.¶

The implementer and the operator deploying need to be aware of default order of actions and the interactions between any set of FSv2 actions.¶

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

                    Figure 3-9

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

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

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

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

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

              Figure 3-10

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

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

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

                  Table 3-6
  Conflicts between FSv2 Transitive Generic IPv4 actions

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

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

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

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

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

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

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

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

 Generic Transitive Extended Community (IPv4)

   0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Type high    |  Type low     |ACO-dependency |  AC-Failure   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         AC-Failure value  (4 octets)                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3-11

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 FSv2 Filters and Actions

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

This section describes how to order FSv2 filters received from a peer prior to transmission to another peer. The same ordering should be used for the ordering of forwarding filtering installed based on only FSv2 filters.¶

Section x.x describes how a BGP peer that supports FSv1 and FSv2 should order the flow specification filters during the installation of these flow specification filters into FIBs or firewall engines in routers.¶

The BGP distribution of FSv1 NLRI and FSv2 NLRI and their associated path attributes for actions (Wide Communities and Extended Communities) is “ships-in-the-night” forwarding of different AFI/SAFI information. This recommended ordering provides for deterministic ordering of filters sent by the BGP distribution.¶

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

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

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

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

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

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

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

6.1. BGP FSv2 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-bgp-community-attribute]

Hares, S., "BGP Community Container Attribute", Work in Progress, Internet-Draft, draft-hares-idr-bgp-community-attribute-01, 14 October 2024, <https://datatracker.ietf.org/api/v1/doc/document/draft-hares-idr-bgp-community-attribute/>.

[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-24, 6 October 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-24>.

[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-20, 16 June 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-nvo3-20>.

[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., [email protected], Ray, S., Mohapatra, P., Henderickx, W., Simpson, A., and M. Texier, "BGP Flow-Spec Redirect-to-IP Action", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-03, 8 September 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-03>.

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

[RFC0791]

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

[RFC2119]

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

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4360]

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

[RFC4456]

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

[RFC4760]

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

[RFC5065]

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

[RFC5701]

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

[RFC7153]

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

[RFC7606]

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

[RFC8174]

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

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/info/rfc8955>.

[RFC8956]

Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., "Dissemination of Flow Specification Rules for IPv6", RFC 8956, DOI 10.17487/RFC8956, December 2020, <https://www.rfc-editor.org/info/rfc8956>.

[RFC9015]

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

[RFC9117]

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

[RFC9184]

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

[RFC9582]

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

9.2. Informative References

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