Internet-Draft BGP FSv2 More IP Actions October 2024
Hares Expires 20 April 2025 [Page]
Workgroup:
IDR Working Group
Internet-Draft:
draft-hares-idr-fsv2-more-ip-actions-03
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 FSv2 actions in Extended Communites. This draft suggests additional IP actions for FSv2 in a BGP Community path attribute.

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 20 April 2025.

▲

Table of Contents

1. Introduction

Version 2 of BGP flow specification (FSv2) is contained in a series of specifications ([I-D.ietf-idr-fsv2-ip-basic]), [I-D.hares-idr-fsv2-more-ip-filters]), this document, and individuals specifications for IP Filters, IP actions, and non-IP actions (MPLS, L2, SFC and tunneled IP). This draft defines user-ordered FSv2 actions encoded in a BGP Community Path Attribute and how these actions interwork with the FSv2 actions encoded in Extended Community attributes.

The remainder of this Introduction section provides an overview of the FSv2 specifications.

Section 2 contains a description of the format of the user ordered actions encoded in the BGP Community Path Attribute in the FSv2 TLV. Section 3 provides information on Validation and Error handling for the FSv2 Actions when the BGP Community Path Attribute is attached to the BGP update message. Sections 4-6 contain considerations for manageability security and IANA considerations for the FSv2 user ordered ations.

1.1. FSv2 Introduction

BGP Flow Specification version 1 (FSv1) defined in [RFC8955], [RFC8956], and [RFC9117] specifies 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:

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

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

  • L2 (AFI=6, SAFI=TBD1),

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

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

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

  • BGP/MPLS L2VPN (AFI=25, SAFI=TBD2), and

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

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.

Version 2 of BGP flow specification was originally 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 was split into a group of functionations that implementers can decide to upgrade. The basic functionality that all FSv2 implementations are required to implement is a FSv2 NLRI format that allows user ordered FSv1 components. Just as in FSv1, the FSv2 allows the passage of actions in Extended community (see [I-D.ietf-idr-fsv2-ip-basic]).

Implementers may optionally add to FSv2 basic functions the following abilities regarding filters for match criteria for IP packets (see [I-D.hares-idr-fsv2-more-ip-filters]):

  • the ability to pass additional IP-related Components in the Extended IP Filter TLV in the FSv2 NLRI,

  • the ability to signal dependencies between IP Filters, and

  • the ability to signal via a filter group number the filters types of Filters being passed in the FSv2 Extended IP Filters.

While there have been arguments for dependencies between filters, [I-D.hares-idr-fsv2-more-ip-filters] only provides a place holder for signaling dependencies between filters. Implementations of specific filters groups and actions will need to define the specifics of this function.

Implementers may optionally augment the signaling of basic FSv2 Actions with the following functions:

  • the ability to order the multiple actions associated with a filter, and

  • the ability to have dependency between multiple actions.

FSv1 actions in FSv1-EC had problems with multiple actions associated with one filter match taking conflicting actions or having problems when one action failed. The basic [I-D.ietf-idr-fsv2-ip-basic] specification provides a fix for FSv2-EC. User ordering of multiple actions and dependency within filters are other methods to fix these problems. This document defines how to carry user-ordered FSv2 Actions in a BGP Community Path Attribute. Space is left within that attribute to have future specifications define action dependency, but those procedures are out of scope for this document.

1.2. 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 persists across a reboot of software module within a routing system or a reboot of a hardware routing device.

  • CPA - BGP Community Path Attribute

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

  • FS-EC - Flow Specification Actions in Extended Community

  • FSv1-EC - FSv1 Actions in Extended Community

  • FSv2-EC - FSv2 Actions in Extended Community

  • FSv2-CPA - FSv2 Actions in BGP Community Path Attribute

  • 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.3. 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 Community Path Attribute. User ordering of FSv2 actions requires using the Community Path Attribute. This section reviews the describes the format of FSv2 actions in Extended Communities or Community Path Attributes.

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 an Extended Community.

Three problems exist with FSv1 actions encoded in an Extended Community:

Conflicts between Actions:
Actions may conflict so ordering is important. For example, traffic rate limit by bytes and traffic rate limit by packets may conflict so order is important.
Actions upon failures:
If an action fails, it is undefined in FSv1 what happens. Implementations may choose different resolutions to an action failure. One FSv1 implementation may choose the "stop on failure" and another may choose a "continue on failure".
No user ordering of actions:
The sender of a FSv1 action cannot provide a user ordering of actions.

FSv2 proposes the following fixes to these problems:

Conflicts between Actions:
A default action order is defined by FSv2 so that the originator and processor know the order of processing.
Actions upon failures:
The actions upon failures are defined by the Action Chain Order (ACO) FSv2-EC action. Implementations operating with a limited domain MAY choose to configure this functionality for all BGP Peers passing FSv2 in the limit domain. However, the ACO FSv2-EC allows users to pass this as an Extended Community across ASes in multiple administrative domains.
No user ordering of actions:
FSv2 allows the optional ordering of BGP FSv2 Actions by using the BGP Path Community specified in this document.

2.1. Format of FSv2 Actions in BGP Community Path Attribute

The BGP Community Path Attribute is defined in: [I-D.hares-idr-bgp-community-attribute] The format for the BGP Community Path Attribute is shown in figure 2-1.


  BGP 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 = FSv2 (1)   |    Flags  |C|T| Reserved      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 2-1

where:

Type:
the type of BGP Path Attribute Community. This document specifies FSv2 BGP Path Attribute container.
Flag:

This one octet field is anoctet of bits with only two bit that can be set as follows:

T = 1 -
Transitive across AS boundaries
T = 0 -
Non-Transitive across AS boundaries
C = 1 -
Transitive across Confederation boundaries
C = 0 -
dNon-Transitive across Confederation boundaries
Reserved:
This one octet is reserved for future use. It is encoded zero for transmission and ignored up reception.
Length:
This two octet field gives the length of the value portion of the BGP Community Path Attribute which consists of the fields shown in figure 2-2. 
FSv2 Action TLV

 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
                              +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                              | FSv2 Action Group (2 octets)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           User Action order                                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Dependency chain ID  (8 octets)                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Action  SubTLVs>+                                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 2-2

Where:

FSv2 Action Group
This 2-octet field specifies the group of Actions passed by the user-ordered FSv2 Actions (see Table 2-4). A BGP peer originating the FSv2 TLV in the BGP CPA may use this to signal which FSv2 actions are supported by the originator.
User Action Order
This is a 4-octet field with the value for user defined action order. A value of zero is reserved. Valid values are 1-0xFFFF.
Dependency chain

this is an 8 octet field with a dependency chain with the format:

version (1 octet):
version of the dependency chain format. Zero signals that no dependency chain is attached. Format versions go from 1 to 0xFF.
chain ID (3 octets):
identifier for action chain. A chain ID of 0x000000 is invalid.
item count (2 octets):
count of items on chain (1-n). The value of 0x0000 specifis no items on list.
item identifier (2 octets):
identifer of item on chain (1-n). An item identifier of 0x0000 is invalid to specify an item.
Dependency chain (8-octets) with all zeros:
means no dependency chain exists.
Action SubTLVs+ (variable):
Sequence of Action SubTLVs with the format of Type-length-value (see figure 2-4). The type fields are defined in Table 2-3
FSv2 Action subTLVS
SubTLVs specifying the FSv2 actions in the format shown in Figure 2-3.

The FSv2 Action TLVs have the following format:

Action SubTLV 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Action type            |  Length                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Action Value                                                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 2-3

Where:

Action type:
This is a 2 octet action type field.
Length:
This is a 2 octet length field for the action value
Action value:
Action values are defined by each action.

2.2. Actions Type Assignments FSv2 BGP Community Path Attribute

The long-term goal of the FSv2 actions is to allow user ordering of the flow specification actions. Only the Community Path Attribute provides enough structured space for user ordering of actions. Table 2-1 shows the FSv2 BGP Community Path Attribute action types for the BGP Community Path Attribute Container for FSv2 actions. These allocations allow transition from FSv2-EC to BGP Path Community by authors of the FSv2-EC.

Support for this document requires the following is supported:

BGP Path Community Attribute
This means the implementation support for parsing of the BGP Path Community Attribute with FSv2 Container for the FSv2 Actions.
Actions TLVs in FSv2 Action Group (AG) [FSv2 AG-1]:
The actions in FSv2 Action Group 1 include actions are listed in Table 2-3. These actions are the FSv2-EC actions specified in [I-D.ietf-idr-fsv2-ip-basic] translated to FSv2-CPA format.

Optionally, implementations may support other actions groups defined in this document. Any unsupported FSv2 Action Groups (FSv2 AGs) may be silently ignored.

 Table 2-1

FSv2 Actions supported in by BGP Community Path Attribute


ID FSv2 H-L  FSv2 Description               Name     FS document
== ========  =============================  =======  ==========
 0 0x80-00   Reserved                       RSV      [This document]
 1 0x80-xx   Action Chain ordering          ACO      [this document]
 2 0x07-02   FS for an Interface set        TAIS     ifset
 3 --------  Reserved                       RSV      [this document]
 4 --------  Reserved                       RSV      [this document]
 5 --------  Reserved                       RSV      [this document]
 6 0x80-06   Traffic rate limit by bytes    TRB      RFC8955
 7 0x80-07   Traffic Action                 TA       RFC8955
             (sample, terminal)

 8 0x80-08   Redirect in various forms      RD       [this document]
                to VRF (2 AS form)          RDIPvrf  RFC8955
 8 0x81-08      to VRF (IPv4 form)          RDIPvrf  RFC8955
 8 0x81-08      to VRF (4 AS form)          RDIPvrf  RFC8955
 8 0x01-0C      to IPv4 / copy              RDIPv4C  RDIP
 8 0x000C       to IPv6 / copy              RDIPv6C  RDIP
 8 0x000D       to VRF (IPv6 form)          RDIP6vrf RFC8956
 8 0x09-xx      to Indirection ID           RGIDC    RGID

 9 0x80-09   Traffic mark DSCP              TM       RFC8955
10 0x80-0A   Traffic rate limit by packets  TRP      RFC8955
11 0x0b-00   SFC Reserved                   SFC-R    RFC9015
             0x01 -SFVC SFIR POOL ID        SFIR-PI  RFC9015
12 0x80-0c   Traffic rate limit by packets  TRP      RFC8955

 RDIPvrf  - redirect to VRF
 RDIP6vrf - redirect to VRF (using IPv6 form)
 RDIPv4C  - redirect to IPv4 address for original or copy
 RDIPv6C  - redirect to IPv6 address for original or copy
 RGID - redirect to global indirection Identifier


Table 2-2 Short Names to IETF documents

 Short-name         Filename
 =================  ===============================
 ifset              draft-ietf-idr-flowspec-interfaceset-05
 RDIP               draft-ietf-idr-flowspec-redirect-ip-03
 RGID               draft-ietf-idr-flowspec-redirect-path



 Table 2-3
 Action Group IDs for groupings of Action Types (AT)

 AG-id  Name    Action Type IDs     Reference
-----  -------  ----------------    --------------
 0x00  RSV      Reserved Group      [this document]
 0x01  Base-IP  ACO, TA, TRB, RD    [this document]
                TRP, SFC
 0x02  If-sets  ACO, TA, TRB, RD,   [this document]
                TRB, TRP, TAIS      [ifset]

2.3. FSv2 Actions in FSv2 Community Path Attribute (FSv2-CPA)

The FSv2 Community Path Attribute could inherits the FSv2 Extended Community actions (FSv2-EC) for FSv1 actions standardized in [RFC8955], [RFC8956], IP Redirect [I-D.ietf-idr-flowspec-redirect-ip], and SFC [RFC9015]

New FSv2-EC must define both an Extended Community form and a Community Path Attribute form.

The following FSv2 BGP Community Path Attribute (FSv2-CPA) Action types created from FSv1 actions will be defined in this section:

ACO (0x01):
action chain order (section 2.3.1),
TAIS (0x02:
Traffic filtes limited by interface set (section 2.3.2)
TRB (0x06):
traffic rate limited by bytes (section 2.3.3),
TA (0x07):
traffic actions (TA) (section 2.3.4),
RD (0x08):
redirect IPv4 (section 2.3.5),
TM (0x09):
Traffic marked with DSCP valiue (section 2.3.6),
SFC (0x0B):
SFC classifiers (section 2.3.7)
TRP (0x0C):
Traffic rate limit by packet (section 2.3.8)

2.3.1. Action Chain Ordering FSv2 Extended Community (ACO (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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x01)     |  Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |ACO-dependency |  AC-Failure   | AC Failure value              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2-4

where:

Action type:
Two octets with type for Action Chain Order (ACO) (value 0x01)
length:
Two octets of length with value 4.
ACO Dependency:

The order dependency within the Action chain.

0 =
default order and interaction. For FSv2-EC this means a pre-defined order and inter-dependency.
1 =
Implementation specific order and interaction.
AC-failure-type:

1 octet byte that determines the action on failure. 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”. AC-Failure types values are:

0x00 =
default – stop on failure
0x01 =
continue on failure (best effort on actions)
0x02 =
conditional stop on failure
0x03 =
rollback – do all or nothing
AC failure value -
2 octet action field zero filled.
Interferes with:
No other FSv2 Action

2.3.2. Traffic Filters based on Interface set (TAIS (0x02)) 


   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x02)     |  Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Interface group                        |O I -  Flags   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  sequence of interfaces                                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Each intrface has the 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |AFI            | SAFI          | interface adddress            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | interface address (continued) (4 or 16 octets)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 2-5

where:

Action type:
Two octets with value 0x0002.
length:
Variable depending on interface addresses
interface group:
Identifier for group (3 octets).
Flags:
1 octet of flag with bit 0 - indicating inbound filters, and bit-1 indicating outbound filters.
sequences of interface addresses:
list of interfaces with the format of AFI/SAFI, address.
Interferes with: TAIS
May interfere with all other actions.

2.3.3. Traffic Rate Bytes (TRB, 0x06) 


   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x06)     |  Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Maximum rate of bytes per second                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2-6

where:

Action type:
Two octets with value 0x0006.
length:
Two octets of length with value 4.
Maximum rate of bytes per second:
These 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being bytes per second. A traffic-rate of 0 should result on all traffic for the particular flow to be discarded. On encoding, the traffic-rate MUST NOT be negative. On decoding, negative values MUST be treated as zero (discard all traffic).
Interferes with: TRP
May interfere with the traffic-rate-packets (TRP). A policy may allow both filtering by traffic-rate- packets and traffic-rate-bytes. If the policy does not allow this, these two actions will conflict.

2.3.4. Traffic Action Bit Mask (TA, 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x06)     |  Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                     6 octet bit mask                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                          |S|T|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 2-7

where:

Action type:
Two octets with value 0x0007.
length:
Two octets of length with value 6.
Traffic Action Field

6 octets of bit mask (0-47) with all values being reserved except S (bit 46) and T (bit 47).

Bit T: Terminal Actions (Bit 47) -
When this bit is set, the traffic filtering engine will evaluate any subsequent FSv2 flow specification (filter and action). f not set, the evaluation of the traffic filters stops when this Flow Specification is evaluated. This halt of FSv2 flow specification process occurs without regard to filter dependency or action dependency.
Bit S: Sample (bit 46) -
When this bit is set, the traffic is sampled and logged for this flow specification.

Interferes with:

Redirect action logic -
Redirect functions which copies may interact with sample.
Filter dependency chain logic -
The user order and filter dependency chain logic may be ignored if the Terminal action is set. This action may be exactly with the user desired or work against the intent of the user.
Action dependency chain logic -
If the user sets multiple actions for a match on a filter, the actions may have an action dependency chain. The Terminal Action may disturb the logic the user intended or be the correct action.

2.3.5. Traffic Redirect (RDIP, 0x08)

Summary:
Redirect traffic upon Match of Filters
Description:
The Traffic redirection actino allows for redirection to specific IP address (with or without a copy), redirection to an indirection-ID which can support local definitions or Segment Routing (SR) definitions for SR-MPLS or SRv6.
Encoding:
Shown in Figure 2-8 

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x08)     |  Length (2 octets)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |       4-ocet AS                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | AFI           | SAFI          | Redirect Type | flags         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  redirect location  (4 octets or 16 octets)                   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 2-8

where:

Action type:
Two octets with value 0x0008.
length:
Two octets of length specific to the AFI/SAFI type. This specification defines the following AFI/SAFI pairs: (1/1), (2/1), (1/128), and (2/128). For IPv4 AFIs, the length is 12. For IPv6 AFIs, the length is 24. Other AFI/SAFI pairs may be defined for this FSv2 action, but these definitions are outside the scope of this document.
4-octet AS:
The 4 octet aS is the AS of the originator of this FSv2 action.
AFI:
The AFI of the redirect location
SAFI:
The SAFI of the redirect location
Redirect Type

The 1-octet redirect type May be one of the following values:

IP VRF (0x00):
Redirect to a VRF identifier
IP Address (0x01):
Redirect IP address encoded as IPv4 or IPv6 address
Redirect by local Indirect ID (0x02):
The 4-octet or 16 octet-value redirection location operates as an indirect ID for localized IP indirection table.
Redirect by Node-ID with SID/index for SR-MPLS (0x03):
The 4-octet redirect location is an indirect ID with the form of a Node ID with SID/index in MPLS-based Segment Routing. This means means the 32-bit indirect ID is mapped to an MPLS label using the index as a global offset in the SID/label space. The 16-octet redirection location is invalid for this redirection type.
Redirect by Node-ID with SID/label for SR-MPLS (0x04):
The 4-octet redirect location has the form of form of a Node ID with SID/label in MPLS-based Segment Routing. This means means the 32-bit redirection location is mapped to an MPLS label using the redirect location as an MPLS label [RFC8402]. The 16-octet redirection location is invalid for this redirection type.
Redirect by Binding Segment ID with SID index for SR-MPLS (0x05>:
The 4-octet redirect location is is mapped to an MPLS binding label using the redirection location as a global offset in the SID/label space) The 16-octet redirection location is invalid for this redirection type.
Redirect by Binding Segment ID (BSID) with SID/Index for SR-MPLS (0x06):
The 4-octet redirection location is mapped to a MPLS binding label using the redirection location as a global label. [RFC8402] The 16-octet redirection location is invalid for this redirection type.
Redirect to Tunnel ID (0x07):
The 4-octet Tunnel ID is within a single administrative domain a 32-bit globally unique tunnel identifier. The allocation and programming of the Tunnel ID within the local indirection-id table is outside scope of the document. The 16-octet redirection location is invalid for this redirection type.
Node ID with SID/index in SRv6 (0x08):
The 4-octet or 16-octet redirection location is mapped to an SRv6 SID using the indirection-id as global SRv6 SID or index.
Binding Segment ID with SID/index in SRv6 (0x09):
The 4-octet or 16-octet redirection location is mapped to an SRv6 binding SID using the the redirection location as an index for global offset in the SID space).
Binding Segment ID with SID/index in SRv6 (0x0a):
The 4-octet or 16-octet redirection location is mapped to an SRv6 binding SID using the indirection-id as global SRv6 SID.
Flags

Where:

RES:
is a 3 bit reserved field
S-ID
is a 4 bit field field for sequence of indirect features. This is a carry-over from the [I-D.ietf-idr-flowspec-path-redirect] functions.
C
is a 1 bit field indicating a copy of the packet. 

  0             1
  0 1 2 3 4 5 6 7
 +-+-+-+-+-+-+-+-+
 | RES | S-ID  |C|
 +-+-+-+-+-+-+-+-+

   Figure 2-9
Interferes with:

FSv2 redirection functions from the following FSv2 Extended Communities (FSv2-EC):

1) Redirect IP FSv2-EC:

See [RFC8955][RFC8956].

Common functions with Redirect types IP Address (0x00) or IP Address copy (0x01). A change of overlapping functions with other redirect types (0x02-0x10).

2) Redirect with copy FSv2-EC:

See [I-D.ietf-idr-flowspec-redirect-ip]).

Common function with redirect of type IP Adress with copy (0x01). A change of overlapping functions with other redirect types (0x01, 0x02-0x10).

3)Redirect for SR-MPLS or SRv6:

See [I-D.ietf-idr-flowspec-path-redirect]

Potential overlap with redirect types (0x02-0x10).

2.3.6. Traffic Marking DSCP (TM, 0x09)

Summary:
Marking DSCP bits in traffic
Encoding:
Encoding is shown in Figure 3-x 

   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x08)     |  Length (2 octets)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |RR | DSCP      | Reserved                                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2-10

where:

Action type:
Two octets with value 0x0009.
length:
4 octets indicating the length of the action value field
RR:
2 bits of zero in DSCP byte.
DSCP
6 bits of DSCP value to mark in the IPv4 packet.
reserved
Reserved - 3 octets of reserved bytes. These bytes are set to zero on transmission and ignored upon receipt.
Interferes with:
No other FSv2 action.

2.3.7. SFC Classifier (SFCC, 0x0B)

Summary:
Action to put traffic into a specific entry point to a SFP.
Description:
The FSv2-EC version of this action is contained in [RFC9015], and this BGP Community Path attribute creates the same function that can be user-ordered FSv2 action. All rules regarding the fields specified in section 7.4 of [RFC9015] are to be utilized for this function. The sub-type identifies the FS-EC action for classifying the flow, and only subtype 0x01 is valid. Other subtypes are outside the scope of this document. If a given FSv2 action in BGP Community Path Attribute does not contain an installed SFPR with the specified identifier by (SPI, SI, SFT), it MUST NOT be used for dispositioning the packets of the specified flow.
Encoding:
See Figure 2-x casts the encoding from section 7.4 of [RFC9015]into the FSv2-CPA. 

Value field for SFC Classifier CPA
                          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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x08)     |  Length (2 octets)            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | sub-type(0x01)|    SPI                                        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  SI           |      SFT      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Figure 2-11: The Format of the Flow Specification for SFC
                 Classifiers Extended Community

where:

Sub-type:
(1 octet) Sub-type. Only valid type is 0x01.
SPI:
(3 octets) Service Path Identifier
SI:
(1 octet) Service Indicator
SFT:
(1 octet) Service Function Type
Interferes with:
Redirect actions

2.3.8. Traffic Rate Packets (TRP, 0x0C) 


   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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |        Action type (0x06)     |  Length                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         Maximum rate of packets per second                    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 2-12

where:

Action type:
Two octets with value 0x0006.
length:
Two octets of length with value 4.
Maximum rate of bytes per second:
These 4 octets carry the maximum rate information in IEEE floating point [IEEE.754.1985] format, units being packets per second. A traffic-rate of 0 should result on all traffic for the particular flow to be discarded. On encoding, the traffic-rate MUST NOT be negative. On decoding, negative values MUST be treated as zero (discard all traffic).
Interferes with: TRB
May interfere with the traffic-rate-bytes (TRP). A policy may allow both filtering by traffic-rate- packets and traffic-rate-bytes. If the policy does not allow this, these two actions will conflict.

3. Validation and Ordering of Actions

3.1. Validation of Flow Specification Actions

FSv2 actions may associate actions using Extended Communities or the BGP Community Path attribute (FSv2-CPA) with FSv2 NLRIs. All the NLRIs in an UPDATE packet are associate with a FSv2 action found in either the FSv2-EC or the FSv2-CPA.

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, or 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 are logically linked to the filter rule(s) in the NLRI in the path in ordered as described in section 3.2. 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).

3.2. Ordering of Actions

The normal processing of FSv2 actions are by user order. The default ordering involves processing of the Actions specified by the BGP Path Community followed by the Extended Community ordering.

The ordering of precedence for these FSv2 actions set in BGP Path Community and Extended Community are:

First by user order for action. -
The user specified order can go from 1-N where N is 0x8000 by default. The user order value of zero is invalid. All FSV2-EC should be assigned a starting point A configuration knob should allow setting the user order value for all FSv2-EC.
If two FSv2-CPA actions have same user order, then by action type. -
Action types are in Table 2-1. If Both FSv2-CPA and FSv2-EC are configured, the user types will be separated
If two FSV2-CPA actions have the same user order, same action type, then by action value.
Each action type must specify the combination.

During initial deployment of BGP Path Community, implementations may wish to set all Extended Community orders to 1, and assign user order values of 2-N. A configuration knob should be added to indicate this alternative assignment of order.

All Extended Community actions and Path Community attributes should be ordered in the action number specified in Table 3-1.

3.3. Summary of FSv2 ordering

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


Summary of ordering by FSv2-CPA Default order of actions

FS Action                           Value Order
(lowest value to highest)          (lowest to highest)
================================   ==============================
0x01: ACO: Action chain operation  dependency value, failure value
0x02  TAIS:Traffic actions per     AS, then Group-ID, then Action ID
       Interface group
0x06: TRB: Traffic rate limit      AS, then float value
      by bytes
0x07: TA: Traffic Action           Traffic action value
0x08: RD                           first by sub-type (0x00-0x0A)
                                   then by value,
      RDIPvrf: Redirect to VRF     AS, then IP Address, then ID
      RDIP6vrf: Redirect to VRF    IPv6 address, then ID
      RDIPv4C: Redirect to IP/Copy AS, then IP address, then ID
      RDIPv6C: Redirect to IPv6    AS, then IPv6 value, then local Admin
      RGIDC: Redirect via type to  AS, then type, then Generalized-ID
       Generalized Identifier

0x09: TM: Traffic Marking          DSCP value (lowest to highest)
0x0b: SFCC:                        sub-type, SFI, SI, SFT
0x0C: TRP: Traffic Rate limit      AS, then float value
         by bytes

Notes:

The RDIPvrf forms without an AS should use AS of 4-octets of zero.
The RDIPvrf form with 2-octet AS should normalize to 4-octet as
(high 2-octets are zero).



                 Figure 3-1

4. Error handling

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

Please note that these rules augment the FSv2 rules for NLRI which state:

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. IANA Considerations

This section complies with [RFC7153].

5.1. FSV2 Action TLV Types

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


   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: Filters by interface set  [this document]
          interface group                 [this document]
   0x03   Unassigned                      [this document]
   0x04   Unassigned                      [this document]
   0x05   Unassigned                      [this document]
   0x06   TRB: traffic rate limit (bytes) [this document]
   0x07   TA: Traffic action              [this document]
   0x08   Redirect (all types)            [this document]
   0x09   TM: traffic marking (DSCP)      [this document]
   0x0C   TRP: traffic rate limit (pkts)  [this document]
   0x00D-
   0x3ff  Unassigned                      [this document]
   0x4000-
   0x7fff Vendor assigned                 [this document]
   0x8000-
   0xFFFF Reserved                        [this document]

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

7. References

7.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, , <https://datatracker.ietf.org/api/v1/doc/document/draft-hares-idr-bgp-community-attribute/>.
[I-D.hares-idr-fsv2-more-ip-actions]
Hares, S., "BGP Flow Specification Version 2 - More IP Actions", Work in Progress, Internet-Draft, draft-hares-idr-fsv2-more-ip-actions-01, , <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-more-ip-actions-01>.
[I-D.hares-idr-fsv2-more-ip-filters]
Hares, S., "BGP Flow Specification Version 2 - More IP Filters", Work in Progress, Internet-Draft, draft-hares-idr-fsv2-more-ip-filters-03, , <https://datatracker.ietf.org/doc/html/draft-hares-idr-fsv2-more-ip-filters-03>.
[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-24, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-l2vpn-24>.
[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-20, , <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, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-path-redirect-12>.
[I-D.ietf-idr-flowspec-redirect-ip]
Uttaro, J., Haas, J., akarch@cisco.com, 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, , <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, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-flowspec-srv6-05>.
[I-D.ietf-idr-fsv2-ip-basic]
Hares, S., Eastlake, D. E., Dong, J., Yadlapalli, C., and S. Maduschke, "BGP Flow Specification Version 2 - for Basic IP", Work in Progress, Internet-Draft, draft-ietf-idr-fsv2-ip-basic-01, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-fsv2-ip-basic-01>.
[I-D.ietf-idr-rpd]
Li, Z., Ou, L., Luo, Y., Mishra, G. S., Chen, H., and H. Wang, "BGP Extensions for Routing Policy Distribution (RPD)", Work in Progress, Internet-Draft, draft-ietf-idr-rpd-19, , <https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-19>.
[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>.

7.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>.
[RFC8402]
Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.

Author's Address

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