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 and processing of the user ordered actions encoded in the BGP Community Path Attribute in the FSv2 TLV. Section 3 describes Action Components supported by FSv2. Section 4-5 provides information on validation, manageability, and error handling for the FSv2 Actions when the BGP Community Path Attribute is attached to the BGP update message. Sections 6 and 7 contain considerations security and IANA considerations for the FSv2 user ordered actions.

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). BGP Flow Specification version 2 (FSv2) defined in () a new FSV2 AFI (TBD1) with two SAFIs (TBD2 (Unicast) and TBD3 (VPN)). FSv2 allows for user ordering of filters, dependency between filters, and specifying some component filters as mandatory or optional. 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. A complete solution for FSv2 Actions to do the following requires more space than is available in BGP Extended Communities. a user specified-order between the multiple actions associated with a filter, and have dependency between multiple actions. This document defines how to carry user-ordered FSv2 Actions in a BGP Community Path Attribute ( The following types of actions were defined in in section 4.9.1 group, redirect, Mark, Merge or traffic shape, Flag traffic for sampling, terminate processing instructions, or logging,

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 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 defines the FSv2 Container for the BGP community Path attribute. This section defines a FSv2 Action in the BGP Community Path Attribute. The first section reviews the format of the BGP Community Path Attribute. The second section defines the BGP Community Container and the Sub-TLV types allowed within the container. The third section summarizes how the content of FSv2 Container is processed.

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

Type: (TBD4)

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.

Editor's note: Should this section be dropped?

The FSv2 Action Container allows for grouping of multiple FSv2 actions

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 length | | (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dependency chain ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User order (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action subTLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Where:

Action length: This 2-octet field specifies ID for the set of FSv2 actions passed in the BGP container TLV.
Dependency chain: A 32-bit unsigned integer in network byte order. When non-zero, the Dependent Filters Chain value is used to associate multiple NLRI together that share dependencies.
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.
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: specifying the FSv2 actions in the format shown in Figure 3.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FSv2 Action Family type | Fsv2 Action Family length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+--+-+ | FSv2 Action Component TLVs (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Where:

Fsv2 Action Family type (2 octets):: (2 octets)the following 100 - action failure processing 200 = group, 300 - redirect, 500 - Mark, Merge or traffic shape, 700 - Flag traffic for sampling, 900 - terminate action instructions, or 1000 - logging, 4095 - reserved Note: all values not defined are unassigned
FSv2 Action Family length (2 octets):: is the length of the list of FSv2 action components within the Family type.
FSv2 Action Component TLVs: (variable):: Defined below (figure 4 and text descriptiosn)

Action Comoponent 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Action compnent type | Length | | 4 bits| 12 bits | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action component value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Where FSv2 Action Flags are defined as:

Action Flags 0 1 2 3 +---+---+---+---+ | O | R | R | R | +---+---+---+---+ Figure 5 Where the fields are defined as:

O - Optional:: When 0, the FSv2 action component is mandatory and MUST be supported by the local implementation. Otherwise, when 1, the action component is considered "optional". When the component is mandatory and is not supported, the FSv2 filter rule is considered "invalid" for validation purposes.
R - Reserved:: When not otherwise re-defined in a later document, this bit MUST be set to zero when sent and SHOULD be ignored on reception.
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.

FSv2 Community container actions allow user-ordered actions to be associated with a filter-match rule. Each FSv2 rule may have one or more match conditions and one or more associated actions. defines FSv2 NLRI operates in ships-in-the-night with the FSv1 NLRI. Flow Specification Extended Community actions can associated with FSv1 NLRI or FSv2 NLRI. Specifications for FSv2 Action are required to specify in the document how actions in the same action category (see 4.9 ). In practice, FSv1 actions in implementations define by configuration how action in the same category interoperate. The precedence between FS Actions in Extend Community actions and the FSv2 Community Container Actions is that the FSv2 Community Container actions take precedence before the FSv2 Extended Community actions. If local policy alters that precedence between FS Extended Community actions and FSv2 Community container actions, it possible that the actions may have undesired effects due to the ordering of actions. The basic principles for FSv2 Community container actions follows the definitions found in in section 3 that specify transitivity across Administrative and AS boundaries, Transitivity across AS confederation boundaries. The FSv2 Community Container re-uses the concepts of the FSv2 NLRI (dependency chain, user order, mandatory or optional action components). the specific rules of processing the data within the FSv2 Community container for FSv2 are: Actions are ordered first user-specified ordered carried in the FSv2 Action Container in the Community Attribute. Numerically smaller user-specified order values have better precedence than larger values. For actions with the same user-specified order, the actions then ordered by FSv2 action family type, then FSv2 action component type, and then the rules for each component type. Each FSv2 Action Community Container defines its own rules governing FSv2 actions within the compnent. Editor: The family type helps the default ordering of actions. Is this additional layer useful?

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 Continue option (100) | Length (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACO-dependency | AC-Failure | AC Failure value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-4 where:

Action famiily:

Action Failure

Action component:

Two octets with type for Action Continue Option (100)

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Interface set | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface group |O I - Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sequence of interfaces SubTLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each interface 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 Family:: Grouping
Action Component:: Two octets with value 0x0002.
length:: Group filters by interface set
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.

The Redirect actions in Extended Community are included in Table 2-1. The Redirect traffic component replaces these with a single action component that has ordering rules within the component.

Table 2-1 FSv2 Actions supported (Extended Community) ID FSv2 Description Name FS document == ============================= ======= ========== 100 Redirect with sub-byte for Redirect to VRF (2 AS form) RDIPvrf RFC8955 to VRF (IPv4 form) RDIPvrf RFC8955 to VRF (4 AS form) RDIPvrf RFC8955 to IPv4 / copy RDIPv4C RDIP to IPv6 / copy RDIPv6C RDIP to VRF (IPv6 form) RDIP6vrf RFC8956 to Indirection ID RDIDC RGID to SFC Path RDSFP RFC9015

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 Familiy:

Redirect

Action type:

Two octets with value 0x0008.

length:

length of SubTLV

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:

VRF (100):: Redirect to a VRF identifier
IP address(200):: Redirect IP address encoded as IP address (AFI/SAFI)
Redirect by local Indirect ID (300):: 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 (400):: 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 (500):: 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 (600):: 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/label for SR-MPLS (700):: 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 (800):: 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 (900):: 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 (1000):: 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 (1100):: The 4-octet or 16-octet redirection location is mapped to an SRv6 binding SID using the indirection-id as global SRv6 SID.
SFC path (1200):: SFC Path(see below)

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).
4) Redirect FS-EC for SFC Path: see

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

Mark Merge Shape Traffic action Components

Action Coponent	Description	Reference
0	Reserved	[this document]
100	DSCP mark	[this document]
200	Mark IPv4 CSID	draft-lin-idr-cats-flowspec-ts
210	Mark IPv6 CSID	draft-lin-idr-cats-flowspec-ts
210	Mark IPv6 CSID	draft-lin-idr-cats-flowspec-ts
300	set Traffic rate limits	[this draft]
400	sample-copy	[this draft]

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.

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 (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | type of rate limit | length of rate field | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum rate of bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-6 where:

Action Family:: Mark, Merge and Sahpe Traffic Family
Action component type:: Two octets with value 0x0006.
length:: Two octets of length with value 4.
type of rate field: type of rates (byte, packet, CATs packets)
length of rate field: 4 bytes - if byte, packet, or CATS packets)
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Sample (400) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sample/Copy Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-7 where:

Action Family type:: Mark, Merge, Sample Traffic
Action type:: Two octets (100)
length:: Two octets of length with value 6.
Sample/Copy Value: 2 bytes of copy type

Interferes with: TBD

Summary:: Terminate FS Aciton chain.
Description:: stops the action change at this action.
Encoding:: See Figure 2-x casts the encoding from section 7.4 of into the FSv2-CPA.

Value field for Terminate FS Action 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | component type (100) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | action upon Termate | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-11: Format of the where:

Action Family type:: Terminate action
component type:: (2 octets) 100
length:: (2 octets> length of action
action upon terminate:: (2 octets) actions upon termination

Editor: actions can include logging, checking something else, or perhaps an action chain. Need to add more here.

FSv2 actions may associate actions using Extended Communities or the BGP Community Container attribute (FSv2-BCA) with FSv2 NLRIs. All the NLRIs in an UPDATE packet are associate with a FSv2 action found in either one or more FSv2 actions in an Extended Community or a FSv2 BGP Community container. Actions may conflict, duplicate, or complement other actions. FSv2 BGP Community container actions have precedence over the FSv2 actions in an Extended Community. Well-formed syntactically correct actions are logically linked to the filter rule(s) in the NLRI in the BGP Path Attributes. 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 first by user order. Within the same user order, by Action family type in ascending Order where lower numbers have more precedence. Within the same user order and action family type, by action component type where lower numbers have more precedence. Within the same user order, action family type, and action component type, the component must specify precedence.

It is important that the operator consider where actions can successfully be implement in computer hardware. For example, if a flow specification action to mark traffic at a particular node cannot be done with the router's hardware, the distribution of flowspec rules with actions may be successful but the FSv2 actions fail. This failure to mark a DSCP may cause other problems.

The following error handling rules must be followed by all BGP speakers which support FSv2 Community Attribute: A Malformed BGP Community Container Attribute 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 assign a assign a value from the "BGP Community Container Types" registry in the BGP Parameters group with the value (TBD4) for "Flow Specification Action Container".

IANA is requested to create the a new registry for "Flow Specification v2 Action Family Types". Registration Procedures: 0x01-0x3FFF Standards Action. Flow Specification v2 Action Family Types

Type	Description	Reference
0	Reserved	[this document]
1-99	Unassigned	[this document]
100	Action Failure	[this document]
101-199	Unassigned	[this document]
200	group	[this document]
201-299	Unassigned	[this document]
300	redirect	[this document]
301-499	Unassigned	[this document]
500	Mark,Merge or Traffic Shape	[this document]
501-699	Unassigned	[this document]
700	Flag traffic for sampling	[this document]
701-899	Unassigned	[this document]
900	terminate action instructions	[this document]
901-999	Unassigned	[this document]
1000	logging	[this document]
1001-4094	Unassigned	[this document]
4095	reserved	[this document]

IANA is requested to create the following entries on a new "Flow Specification v2 Action Component Registry. Registration Procedures: 0x01-0x3FFF Standards Action. Initial values TBD

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.