BGP Flow Specification Version 2

Version 2 of BGP flow specification (FSv2) is contained in a series of specifications (), ), 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.

BGP Flow Specification version 1 (FSv1) defined in , , and 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 (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 ). Implementers may optionally add to FSv2 basic functions the following abilities regarding filters for match criteria for IP packets (see ): 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, 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 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.

AFI - Address Family Identifier AS - Autonomous System BGPSEC - secure BGP updated by 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 . RESTCONF - The RESTCONF configuration Protocol RIB - Routing Information Base ROA - Route Origin Authentication RR - Route Reflector. SAFI – Subsequent Address Family Identifier

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 when, and only when, they appear in all capitals as shown here.

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 or in the Extended IPv6 Community format . 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.

The BGP Community Path Attribute is defined in: The format for the BGP Community Path Attribute is shown in figure 2-1.

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.

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

The FSv2 Community Path Attribute could inherits the FSv2 Extended Community actions (FSv2-EC) for FSv1 actions standardized in , , IP Redirect , and SFC 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)

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

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.

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.

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.

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

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 . 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. 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 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 . 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 ). 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 Potential overlap with redirect types (0x02-0x10).

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

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.

Summary:: Action to put traffic into a specific entry point to a SFP.
Description:: The FSv2-EC version of this action is contained in , 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 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 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

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.

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

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.

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

The following error handling rules must be followed by all BGP speakers which support FSv2 Community Attribute: A Malformed Community Path Attribute container shall be considered malformed if any action TLVs or the Community container which is malformed. FSv2 Community Path attributes having TLVs which do not follow the FSv2 ordering rules described in this document MUST be considered as malformed by a BGP FSv2 propagator. An Update with a malformed Community Path Attribute shall execute the "treat-as-withdaw" behavior Note that a BGP speaker MUST NOT TLV type in the FSv2-CPA as an error. Please note that these rules augment the FSv2 rules for NLRI which state: FSv2 NLRI having TLVs which do not have the correct lengths or syntax must be considered MALFORMED. FSv2 NLRIs having TLVs which do not follow the FSv2 ordering rules described in section 4.1 MUST be considered as malformed by a BGP FSv2 propagator. The above two rules prevent any ambiguity that arises from the multiple copies of the same NLRI from multiple BGP FSv2 propagators. A BGP implementation SHOULD treat such malformed NLRIs as ‘Treat-as-withdraw’ An implementation for a BGP speaker supporting both FSv1 and FSv2 MUST support the error handling for both FSv1 and FSv2.

This section complies with .

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]

The use of ROA improves on by checking to see of the route origination. This check can improve the validation sequence for a multiple-AS environment. >The use of BGPSEC 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 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.