Internet-Draft BGP FlowSpec v2 May 2024
Hares Expires 9 November 2024 [Page]
Workgroup:
IDR Working Group
Internet-Draft:
draft-hares-idr-fsv2-more-ip-actions-00
Published:
Intended Status:
Standards Track
Expires:
Author:
S. Hares
Hickory Hill Consulting

BGP Flow Specification Version 2 - More IP Actions

Abstract

The BGP flow specification version 2 (FSv2) for Basic IP defines user ordering of filters along with FSv1 IP Filters and FSv1 actions. This draft suggests additional IP Filters for Flow Specification FSv2.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 9 November 2024.

▲

Table of Contents

1. Introduction

Version 2 of BGP flow specification was original defined in [I-D.ietf-idr-flowspec-v2] (denoted FSv2). However, the full FSv2 specification contains more than initial implementers desired. Therefore, this original FSv2 draft remains an WG draft, but the content will be split out into functions that implementers can manage. Section 1.4 contains the list of documents intended to be the split of the original FSv2 documents.

FSv2 specifies new user-ordered filters that will be used with the IPv4 (AFI=1) and IPv6 (AFI=2) 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended).

This draft specifies defines extensions to the FSv2 Basic IP package [I-D.hares-idr-fsv2-ip-basic]to support additional IP filters for IP packet and payload. The filters are passed in the Extended IP Filters (type 2) of the subTLVs. This filter form contains a filter version number so filters can be added easily.

BGP Flow Specifiction version 1 (FSv1) as defined in [RFC8955], [RFC8956], and [RFC9117] specified 2 SAFIs (133, 134) to be used with IPv4 AFI (AFI = 1) and IPv6 AFI (AFI=2). FSV2 specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended). The first SAFI (TBD1) will be used for IP forwarding, and the second SAFI (TBD2) will be used with VPNs. The supported AFI/SAFI combinations in FSV2 are:

FSv2 specifies new IP filter that will be used with the IPv4 (AFI=1) and IPv6 (AFI=2) 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended). This document specifies IP filters used with IPvr (AFI=1) and IPv6 (AFI=2).

FSv1 and FSv2 use different AFI/SAFIs to send flow specification filters. Since BGP route selection is performed per AFI/SAFI, this approach can be termed “ships in the night” based on AFI/SAFI.

Section 2 contains a description of the format of the FSv2 actions in Extended Communities and Wide Communities.

The issue with Extended Communities is that multiple Extended Communities might conflict with each other. Section 3 describes which FSv2 actions defined for Extended Communities might conflict each other.

Sections 4 and 5 provide a short description of new actions proposed for FSv2. Section 4 provides a description of the Action Chain Ordering proposed for the FSv2 for Basic IP ([I-D.hares-idr-fsv2-ip-basic]. Section 5 lists the potential new actions from FSv2 actions described in IDR WG drafts or proposed as individual drafts.

Sections 6, 7, and 8 provide information on validation, ordering, and error handling of FSv2 actions. Section 6 describes validation of actions and ordering of actions (user ordered and default). Section 7 describes error handling for FSv2 actions. Section 8 provides an example for ordering of actions.

Section 9 provides details on IANA considerations

1.1. Definitions and Acronyms

  • AFI - Address Family Identifier

  • AS - Autonomous System

  • BGPSEC - secure BGP [RFC8205] updated by [RFC8206]

  • BGP Session ephemeral state - state which does not survive the loss of BGP peer session.

  • Configuration state - state which persist across a reboot of software module within a routing system or a reboot of a hardware routing device.

  • DDOs - Distributed Denial of Service.

  • Ephemeral state - state which does not survive the reboot of a software module, or a hardware reboot. Ephemeral state can be ephemeral configuration state or operational state.

  • FSv1 - Flow Specification version 1 [RFC8955] [RFC8956]

  • FSv2 - Flow Specification version 2 (this document)

  • NETCONF - The Network Configuration Protocol [RFC6241].

  • RESTCONF - The RESTCONF configuration Protocol [RFC8040]

  • RIB - Routing Information Base.

  • ROA - Route Origin Authentication [RFC6482]

  • RR - Route Reflector.

  • SAFI – Subsequent Address Family Identifier

1.2. RFC 2119 language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals as shown here.

2. Format of 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.

This section review FSv1 actions in Extended Communities (IPv4 and IPv6), conflicts between FSv1 actions, and the format Wide Community attribute for FSv2 actions. This section provides background on FSv2 actions beyond the FSv1 actions that will be carried over into FSv2 specifications.

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, but will be ordered by default. The implementer and the operator must be aware of interactions between any FSv2 actions must be specified in the extended community.

The Community attribute [I-D.ietf-idr-wide-bgp-communities] describes an attribute with flexible format for specifying community information This specification specifies with a new FSv2 specific type (type = TBD) can support user ordered actions and dependency between actions. This specification only specifies that format to provide hints for the implementer

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

2.1. Encoding FSv2 Actions in Generic Transitive Communities

The FSv2 actions encoded in Generic Transitive communities inherit the FSv1 actions in Generic Transitive communities.

The Extended Community encodes the Flow Specification actions in the Extended Community format as generic transitive extended communities per [RFC4360] per [RFC8955], [RFC9117], and [RFC9184].

The format of the these actions can be:

Generic Transitive Extended Community (0x80):
where the Sub-Types are defined in the Generic Transitive Extended Community Sub-Types registry.
Generic Transitive Extended Community Part 2(0x81):
where the Sub-Types are defined in the Generic Transitive Extended Community Part 2 Sub-Types registry.
Transitive Four-Octet AS-Specific Extended Communit(0x82):
where the Sub-Types defined in the Generic Transitive Extended Community Part 3 Sub-Types registry.
Generic Transitive Extended Community Part 3 (0x83):
where the Sub-Types defined in the Transitive Opaque Extended Community Sub-Types" registry. 

  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 Generic Transitive Extended Community
          Part 1 - (0x80)

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

                                Figure 3-10

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

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

              Figure 3-11

Table x-x Generic Transitive Extended Community
                  Part 3 (Type 0x82)
Value   Description                  Name  Reference
=====   =======================      ====  ==========
0x08    Flow spec rt-redirect        RDIP  [RFC8955]
        AS-4 octet format

             Figure 3-12

            Table x-x: Traffic Action bits

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

              Figure 3-13

2.2. Encoding Path Forwarding in IPv4 Transitive Extended Communities

FSv2 needs to refine the following Transitive Extended Communities that are not "Transitive Generic Communities" to a specific set of functions. These features provide overlapping functions. While some of these features are implemented, these actions should be be reviewed.

There are three types of functions:

    Table x-x Transitive Extended Community types (T-EC-types)

sub-type   FSv1 Description     Name   Reference
========   ==================   =====  =================
0x07       FS Interface set     Ifset  [IDR-WG-ifset]
0x08       FS Redirect/         RIPv4  [IDR-WG-redirect-ip]
           Mirror
0x09       FS Redirect to
           Indirection-id       RGID   [IDR-WG-redirect-iid]

                        Figure 3-14

2.3. Encoding FSv2 Actions in IPv6 Extended Community

The IPv6 Extended Community encodes the Flow Specification actions in the Extended Community format [RFC5701] per [RFC8956], [RFC9117], and [RFC9184] in the transitive opaque 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-15

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 x-x transitive IPv6-Address-Specific Actions
Value   Description                  Name   Reference
=====   =======================      =====  ==========
0x01    Flow Spec Action Chain       ACO    [This document]
0x0C    Flow Spec redirect-v6-flag   RD6F   [IDR-WG-RD6f]
0x0D    Flow Spec rt-redirect        RDv6   ]RFC8956]
        IPv6 format
                >
              Figure 3-16

2.4. FSv2 Actions encoded in Community Attribute

The user ordered FSv2 Actions use the Communities Path Attribute defined in [I-D.ietf-idr-wide-bgp-communities]. The Community BGP Path attribute is a flexible Community container which allows different formats for different community applications. The FSv2 Community Type ([FSv2-CA], type=TBD1) is only used for FSv2 user-ordered actions.

If both the Extended Community FSv2 Actions (FSv2-EC) and the FSv2 Community Attribute actions are specified (FSv2-CA) then the default preference will be the FSv2-CA prior to the FSv2-EC. This preference may be changed based on a configuration knob. However, this configuration MUST be consistent within an Autonomous System or a group of Autonomous Systems where both the FSv2-CA and FSv2-EC are deployed.

2.4.1. FSv2 Actions in Community Path Attribute

TheCommunity attribute (Type = BGP Community Container, value 34)


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

                          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

                          figure 3-19

The FSv2 Action TLVs have the following 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           User Action order                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Dependency chain ID                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence of Action TLVs                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Each Action TLV has the format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Action type            |  Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence of Action TLVs                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          figure 3-20

3. Conflicts in FSvv2 Extended Communities Actions

3.1. Conflicts between FSv1 Actions 

Table x-x: Conflicts between FSv2 Transitive Generic IPv4 actions

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

              Figure 3-17

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

                              Figure 3-17

4. Actions Proposed for FSv2 for Basic IP

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:

Editors note: The following options for encoding ACO exist.

Option 1:
redefine bits in Traffic Action subtype
Option 2:
create a new Extended Community

4.1. Action Chain Ordering

4.1.1. Option 1: Action Chain operation IPv4 Extended (ACO)(1, 0x01) 

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

SubTLV: 0x01

Length: 6 octets

Value:

  • AC-dependence - 1 octet byte of flag regarding dependency

  • AC-failure-type – 1 octet byte that determines the action on failure

  • AC-failure-value – variable depending on AC-failure-type.

Actions may succeed or fail and an Action chain must deal with it. The default value stored for an action chain that does not have this action chain is “stop on failure”.

where:

  • AC-Failure types are:

    • 0x00 – default – stop on failure

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

    • 0x02 – conditional stop on failure – depending on AC-Failure-value

    • 0x03 – rollback – do all or nothing - depending in AC-Failure-value

  • AC-Failure values: TBD

Interactions with other actions: Interactions with all other Actions

Ordering within Action type: By AC-Failure type

4.1.2. Option 2: Action Chain operation encoded in IPv4 Traffic Action (0x07) 

   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

5. Actions Proposed for FSv2 Actions

5.1. Summary of FSv2 Extended Community [FSv2-EC] in WG (actual or proposed)

Table 4 shows the actions for Extended-Communities FSv2 actions from IDR RFCs, IDR WG drafts and drafts proposed to IDR. Table 6 has FSv2 actions proposed for IPv6. Table 5 contains FSv2 actions that are non-IP actions from IDR WG drafts, and draft proposals. Often, non-IP actions are often linked to IP filters.

 Table 4  All IP Actions in Extended Communities
 act-id Name   Description        Document
 ====== =====  ================   ======================
  00    RSV    Reserved           [this document]
  01    ACO    action chain order [this document]
  02    TBA    Unassigned         [this document]
  03    TAIS   traffic actions    [IDR-FSv2-ifset]
               per interface group

  04    TBA    to be assigned     [this document]
  05    TBA    to be assigned     [this document]
  06    TRB    traffic rate       [RFC8955]
               limited by bytes
  07    TA     traffic action     [RFC8955]
               (terminal/sample)
  08    RDIP   Redirect IPv4      [IDR-FSv2-RDP-ip]
  09    TM     Mark DSCP value     {RFC8955]
  10     TBA    Unassigned        [this document]
  11     TBA    Unassigned        [this document]
  12     TRP    traffic rate      [RFC8955]
                 limit by packet
  13     TISFC  SFC Classifier    [RFC9015]
  14     RDIID  redirect to       [IDR-FSv2-RDPIID]
                 Indirection-id   [PD-FSv2-mobility]
                                 move from 0x00)

  15     TBA    Unassigned        [this document]
  16     TBA    Unassigned        [this document]
  17     NRP-ID Encapsulate       [IDR-net-slice-ts]
                 NRP-ID value

  18    GrP-ID Set Group ID       [PD-peng-group-sub]

            Figure 3-15


 Short-name         Filename
 =================  ===============================
 IDR-FSv2-ifset     draft-ietf-idr-flowspec-interfaceset-05
 IDR-FSv2-linkbw    draft-ietf-idr-linkbandwidth
 IDR-FSv2-RDP-ip    draft-ietf-idr-flowspec-redirect-ip-02
 IDR-FSv2-RDPIID    draft-ietf-idr-flowspec-redirect-path
 IDR-net-slice-ts   draft-ietf-idr-flowspec-network-slide-ts-02
 IDR-FSv2-L2VPN     draft-ietf-idr-flowspec-l2vpn-17
 PD-FSv2-mobility   draft-dmc-flowspec-tn-aware-mobility
 PD-peng-group-sub  draft-peng-idr-apn-bgp-flowspec-00
 PD-redirect-IPv6   draft-ietf0-idr-path-redirect-12

 Table 5  All Non-IP Actions in Extended Communities
 act-id Name    Description        Reference
 ====== =====   ================   ================
 31     TISFC   SFC classifier II  [RFC9015]- moved
 32     MPLSLA  MPLS label action  [RFC9015] -
 33     VLAN    VLAN-Action (0x16) [ID-FSv2-L2VPN]
 34     TPID    TPID-Action (0x17) [ID-FSv2-LVPN
 24-    TBA     to be assigned
  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   [PD-redirect-IPv6]

0x0D    Flow Spec rt-redirect        RD6    [RFC8956]
        IPv6 format

5.2. Actions proposed for FSv2 Community Path Attribte 

 Table 7  All Actions Proposed for FSv2 Community Path Attribute
 act-id Name        Description      Document
 ====== =========   ==============   ======================
  TBD   MatchSet    Match and Set    [I-D.ietf-idr-rpd]
                    attribute
  TBD   MatchNoA    Match and No     [I-D.ietf-idr-rpd]
                    Advertise

  TBD   DetLat      Deterministic    [PD-detnet-flow-mapping-05]
                    Latency action
  TBD   TSNMap          Map flow to      [PD-detnet-flow-mapping-05]
                    TSN stream

6. Validation and Ordering of Actions

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

The precedence for FSv2 actions are 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].

6.1. Validation of Flow Specification Actions

FSv2 actions may specify actions using Extended Communities or the path attribute Community with the FSv2 format. The FSv2 actions in Extended Communities and Wide communities can be associated with large number of NLRIs.

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

6.2. Ordering of Actions

The ordering of precedence for these actions in the case are:

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

Within the actions defined at the same order, the order is:

All Extended Community actions and Path Community attributes should be ordered in the same IP space.

6.3. Summary of FSv2 ordering

Operators should use user-defined ordering to clearly specify the actions desired upon a match. The FSv2 actions default ordering is specified to provide deterministic order for actions which have the same user-defined order and same type.


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

7. Error handling

The following two error handling rules must be followed by all BGP speakers which support FSv2:

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.

8. Example for Ordering of the Actions

8.1. Example of Action Chain Operation (ACO)

The “Action Chain Operation” (ACO) changes the way the actions after the current action in an action chain are handled after a failure. If no action chain operations are set, then the default action of “stop upon failure” (value 0x00) will be used for the chain.

8.1.1. Example 1 - Default ACO

Use Case 1: Rate limit to 600 packets per second

Description: The provider will support 600 packets per second All Packets sampled for reporting purposes and packet streams over 600 packets per second will be dropped.

Suppose BGP Peer A has a

  • a Wide Community action with user-defined order 10 with Traffic Sampling

  • a Wide Community action with user-defined order 11 from AS 2020 that limits packet-based rate limit of 600 packets per second.

  • an Extended Community from AS 2020 that does limits packet-based rate limit of 50 packets per second.

The FSv2 data base would store the following action chain:

  • at user-defined action order 10

    • A user action of type 7 (traffic action) with values of Sampling and logging.

  • at user-defined action order 11

    • a user action type of 12 (packet-based rate limit) with values of AS 2020 and float value for 600 packets per second (pps)

  • at user-defined action order 32768 (0x8000) with type 12 and values of A user action of type 12 with values of AS 2020 and float value of 50 packets/second.

Normal action:

  • The match on the traffic would cause a sample of the traffic (probably with packet rate saved in logging) followed by a rate limit to 600 pps. The Extended community action would further limit the rate to 50 packets per second.

When does the action chain stop?

  • The default process for the action chain is to stop on failure. If there is no failure, then all three actions would occur. This is probably not what the user wants.

  • If there is failure at action 10 (sample and log), then there would be no rate limiting per packet (actions 11 and action 32768).

  • If there is failure at action 11 (rate limit to packet 600), then there would be no rate limiting per packet (action 32768).

The different options for Action chain ordering (ACO) have been worked on with NETCONF/RESTCONF configuration and actions.

8.1.2. Example 2: Redirect traffic over limit to processing via SFC

Use case 2: Redirect traffic over limit to processing via SFC.

Description: The normal function is for traffic over the limit to be forwarded for offline processing and reporting to a customer.

Suppose we have the following 4 actions defined for a match:

  • Sent Redirect to indirection ID (0x01) with user-defined match 2 attached in wide community,

  • Traffic rate limit by bytes (0x07) with user-defined match 1 attached in wide community,

  • Traffic sample (0x07) sent in extended community, and

  • SF classifier Info (0x0E) sent in extended community.

These 4 filters rate limit a potential DDoS attack by: a) redirect the packet to indirection ID (for slower speed processing), sample to local hardware, and forward the attack traffic via a SFC to a data collection box.

The FSv2 action list for the match would look like this

  • Action 0: Operation of action chain (0x01) (stop upon failure)

  • Action 1: Traffic Rate limit by byte (0x07)

  • Action 2: Redirect to Redirection ID (0x0F)

  • Action 32768 (0x8000) Traffic Action (0x07) Sample

  • Action 32768 (0x8000) SFC Classifier: (0xE)

If the redirect to a redirection ID fails, then Traffic Sample and sending the data to an SFC classifier for forwarding via SFC will not happen. The traffic is limited, but not redirect away from the network and a sample sent to DDOS processing via a SFC classifier.

Suppose the following 5 actions were defined for a FSV2 filter:

  • Set Action Chain Operation (ACO) (0x01) to continue on failure (ox01) at user-order 2 attached in wide community,

  • redirect to indirection ID (0x0F) at user-order 2 attached in wide community,

  • traffic rate limit by bytes (0x07)with user-order 1 attached in wide community,

  • Traffic sample (0x07) attached via extended community, and

  • SFC classifier Info (0x0E) attached in extended community.

The FSv2 action list for the match would look like this:

  • Action 00: Operation of action chain (0x01) (stop upon failure)

  • Action 01:Traffic Rate limit by byte (0x07)

  • Action 02:Set Action Chain Operation (ACO) (0x01) (continue on failure)

  • Action 02: Redirect to Redirection ID (0F)

  • Action 32768 (0x8000): Traffic Action (0x07) Sample

  • Action 32768 (0x8000): SFC classifier (0x0E) forward via SFC [to DDoS classifier]

If the redirect to a redirection ID fails, the action chain will continue on to sample the data and enact SFC classifier actions.

9. IANA Considerations

This section complies with [RFC7153].

9.1. FSV2 Action TLV Types

IANA is requested to create the following entries on a new "Flow Specification v2 Action” web page.


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

    Type     Use                           Reference
   -----  ---------------                 ---------------
   0x00   Reserved                        [this document]
   0x01   ACO: Action Chain Operation     [this document]
   0x02   TAIS: Traffic actions per
          interface group                 [this document]
   0x03   Unassigned                      [this document]
   0x04   Unassigned                      [this document]
   0x05   Unassigned                      [this document]
   0x06   TRB: traffic rate
           limited by bytes                [this document]
   0x07   TA: Traffic action
          (terminal/sample)               [this document]
   0x08   RDIPv4: redirect IPv4           [this document]
   0x09   TM: traffic marking (DSCP)      [this document]
   0x0A   AL2: associate L2 Information   [this document]
   0x0B   AET: associate E-Tree
           information                    [this document]
   0x0C   TRP: traffic rate
           limited by packets             [this document]
   0x0D   RDIPv6: Redirect to IPv6        [this document]
   0x0E   TISFC: Traffic insertion
           to SFC                         [this document]
   0x0F   RDIID: Redirect
           to indirection-iD              [this document]
   0x10   MPLS Label Action               [this document]
   0x11   unassigned                      [this document]
   0x12   unassigned                      [this document]
   0x13   unassigned                      [this document]
   0x14   unassigned                      [this document]
   0x15   unassigned                      [this document]
   0x16   VLAN action                     [this document]
   0x17   TIPD action                     [this document]
   0x18-
   0x3ff  Unassigned                      [this document]
   0x4000-
   0x7fff Vendor assigned                 [this document]
   0x8000-
   0xFFFF Reserved                        [this document]

9.2. Wide Community Assignments

IANA is requested to assign values from the Registered Type TBD4 BGP Wide Community Types:


   Name                    type Value
   ------                  -----------
   FSv2 Actions            TBD4

10. Security Considerations

The use of ROA improves on [RFC8955] by checking to see of the route origination. This check can improve the validation sequence for a multiple-AS environment.

>The use of BGPSEC [RFC8205] to secure the packet can increase security of BGP flow specification information sent in the packet.

The use of the reduced validation within an AS [RFC9117] can provide adequate validation for distribution of flow specification within a single autonomous system for prevention of DDoS.

Distribution of flow filters may provide insight into traffic being sent within an AS, but this information should be composite information that does not reveal the traffic patterns of individuals.

11. References

11.1. Normative References

[I-D.hares-idr-fsv2-ip-basic]
Hares, S., Eastlake, D. E., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2 - for Basic IP", Work in Progress, Internet-Draft, draft-hares-idr-fsv2-ip-basic-01, , <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-ip-basic-01>.
[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, , <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, , <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, , <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, , <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, , <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, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect-12>.
[I-D.ietf-idr-flowspec-redirect-ip]
Uttaro, J., Haas, J., Texier, M., akarch@cisco.com, Ray, S., Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to IP Action", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-redirect-ip-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-redirect-ip-02>.
[I-D.ietf-idr-flowspec-srv6]
Li, Z., Li, L., Chen, H., Loibl, C., Mishra, G. S., Fan, Y., Zhu, Y., Liu, L., and X. Liu, "BGP Flow Specification for SRv6", Work in Progress, Internet-Draft, draft-ietf-idr-flowspec-srv6-05, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc5065>.
[RFC5701]
Rekhter, Y., "IPv6 Address Specific BGP Extended Community Attribute", RFC 5701, DOI 10.17487/RFC5701, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc9117>.
[RFC9184]
Loibl, C., "BGP Extended Community Registries Update", RFC 9184, DOI 10.17487/RFC9184, , <https://www.rfc-editor.org/info/rfc9184>.

11.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, , <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, , <https://www.rfc-editor.org/info/rfc6241>.
[RFC8040]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, , <https://www.rfc-editor.org/info/rfc8040>.
[RFC8205]
Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, , <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, , <https://www.rfc-editor.org/info/rfc8206>.

Author's Address

Susan Hares
Hickory Hill Consulting
7453 Hickory Hill
Saline, MI 48176
United States of America
Phone: +1-734-604-0332