BGP Flow Specification Version 2

Version 2 of BGP flow specification (FSv2) has a series of foundational documents (, this document, , and [draft-hares-idr-fsv2-non-ip]) plus drafts on specific filter components, actions, or groups of filter components and actions. The remainder of this introductory section provides a introduction to FSv2. Section 2 contains a description of the format of the FSv2 NLRI with the Extended IP Filters TLV. The Extended IP Filters TLV allows the user to specify new IP Filters components and a group of IP Filter components. The concept of a group of filter components allows an BGP peer originating a FSv2 NLRI with the Extended IP Filter TLV to pass what components the originating BGP Peer expects will be supported by the BGP Peers receiving the FSv2 Extended Filter TLV. The group field is designed to aid upgrades to additional component by providing a simple check the FSv2 component range passed in the Extended Filters TLV. Groups can be register with IANA in either a FCFS range or IETF Consensus range. Section 2 also provides templates for defining: a) new components to be passed in the Extended IP Filter group and b) new Extended IP Filter groups. Section 3 provides two new Filters approved in IDR WG drafts. Section 3.1 provides definitions for new components: TTL, SID in IPv6 Segment Routing header (SRH). These two components were defined in the original specification for Flow Specification v2 (). Section 3.2 also provides prototypes for a few existing components to aid authors of IDR drafts (current or proposed) examples to aid their quick use of the Extended IP Filters. Section 4 provides information on Validation and Error handling for the Extended Filters TLV. Section 5 contains manageability considerations for FSv2 with Extended IP Filters TLV. Section 6 contains IANA considerations and section 7 contains security considerations.

FSv2 specifies new user-ordered filters that will be used with the IPv4 (AFI=1) and IPv6 (AFI=2) 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Extended or Wide Communities). The first SAFI (TBD1) is 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. The full FSv2 specification ( Version 2 of BGP flow specification (FSv2) was original defined in . contains more than initial implementers desired to put in a single upgrade. Therefore, the original FSv2 draft remains an WG draft, but the content will be split out into groups of functions that can be easily deployed as upgrades to FSv1. The upgrades will come in the following groups:

FSv2 IP Basic ():: This specification defines the FSv2 NLRI that allows user ordering of filters plus in a IP Basic TLV which only allows FSv1 components. FSv2 actions are implemented in Extended Communities (FSv2-EC). FSv2 defines how the actions defined in FSv2-EC are ordered. Multiple FSv2-EC actions can be attached to a single filter component, so FSv2 defines an Action Chain Ordering community to define what happens if one of these multiple actions fails. All FSv2 implementations must support the minimal subset in this document.
FSv2 IP Extended Filters (this document):: This document defines the Extended IP Filters TLV to allow easy addition of FSv2 filters. The original FSv2 had definitions for FSv2 TTL and SRv6 Header (SRH) filter so these components are included in this specification.
FSv2 Individual drafts for IP Extended Filters:: These drafts should utilize the template given in section 2.2 Current proposals for Extended IP Filters can request component identifier(s) be included in this draft's BGP FSv2 Component registry list. Grouping of Extended IP Filter can be registered in the Extended IP Filter Groups (see section 2.3).
FSv2 IP Extended Actions ():: This document defines a FSV2 TLV for the for the BGP Community Path Attribute, and a protocols for combining FSv2 Extended Community (FSv2-EC) Actions with FSv2 Community Path Attributes.
FSv2 Individual drafts for FSv2 Actions:: These drafts may define FSv2 actions in Extended Communities and/or FSv2 actions in the FSv2 TLV of the BGP Community Attribute.
Non-IP Filters (draft-hares-idr-fsv2-non-ip]:: defines the template for FSv2 non-IP filters for MPLS, L2 traffic, SFC, and tunnel traffic, and FSV2 non-IP actions.
Individual drafts on Non-IP Filters:: IDR drafts for non-ip functions passed in BGP FSv2 includes: MPLS ([draft-hares-idr-fsv2-mpls]), L2VPN (), and NV03 ().

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.
BGP Configuration state:: state which persist across a reboot of software module within a routing system or a reboot of a hardware routing device.
DDOs:: Distributed Denial of Service.
Ephemeral state:: state which does not survive the reboot of a software module, or a hardware reboot. Ephemeral state can be ephemeral configuration state or operational state.
FS:: Flow Specification.
FSv1:: Flow Specification version 1
FSv2:: Flow Specification version 2 , [this document].
FS-EC:: Flow Specification Extended Community
FSv1-EC:: FSv1 Extended Community that signals actions that occur after a filter match
FSv2-EC:: FSv2 Extended Community that signals actions that occur after a filter match. FSv2-EC are preformed with either a default order of processing or signal the FSv2-EC are performed in implementation order.
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 format of the FSv2 NLRI field for IP Filters is defined in . This format includes a common header with fields for user specified order, dependency filter chain, and a TLV for filter components (type, length, value). This section defines the use of the dependency filter chain (section 2.1) in the NLRI and the format of the Extended IP Filters TLV (section 2.2). The Extended IP Filter group provides a flexible means to define which components are supported by the Extended IP Filter TLV. Four Extended Filter Component groups are defined in section 2.3, but additional may be defined via an IANA Registry. The ordering of Filters is by user define order number, then component, then value within a component. Section 2.4 provides the rules for ordering for FSv2 NLRI with IP Basic Filters and Extended IP Filters. Section 2.5 provides a template for new Extended IP Components.

FSv2 filters may be distributed in multiple BGP UPDATE packets. The format of the FSv2 NLRI is shown in Figure 3-1. In FSv2, the user can define the order of the filters by an including an order in the FSV2 NLRI prior to the filter. FSv2 also defines an optional dependency filter chain to allow the filter chains to be identified across all FSV2 Filter chains. This information may be installed from BGP data based into firewalls.

+-------------------------------+ | NLRI length (2 octets) | +-------------------------------+ | TLVs+ | | +===========================+ | | | order (4 octets) | | | +---------------------------+ | | | Dependent filter chain | | | |(type, chain ID, count, | | | | item) (8 octets) | | | +---------------------------+ | | + FSv2 Filter type + | | | (2 octets) | | | +---------------------------+ | | + length TLVs (2 octet) + | | + --------------------------+ | | + value (variable) + | | +---------------------------+ | +-------------------------------+ Figure 2-1 - FSv2 NLRI with Extended IP Filter type. Where:

order:: 4 octet field for the FSv21 user defined order of the filter with a a value of 1-n. The value of zero is invalid
Dependent Filters Chain:: 8 octets for identifying a chain of FSv2 filters that must be deployed at the same time. (See figure 2-2 for details.) If the dependency filters chain field is also zero, there is no dependency filter chain defined.
FSv2 Filter type:: 2 octet field for the FSv2 filter type. The Extended IP Filter type value is 2.
length:: 2 octet field for the length of the value field.
value field:: variable length field defined per FSv2 filter type. The value field for the Extended IP Filter rules has the format shown in Figure 2-3.

The dependency filter chain has the following components:

+-------------------------------+ | Version (1 octet) | +-------------------------------+ | chain id (3 octets) | +-------------------------------+ | Count of items (2 octets) | + ------------------------------+ | Item (2 octets) | +-------------------------------+ Figure 2-2 – IP header SubTLV format where:

Version:: This 1 octet field defines the version of the filter chain. Valid values are 1-0xFF. Value 0 is reserved.
Chain ID:: This 3 octet field identifies the filter chain. Valid values include 0x00001 to 0xFFFFFF with the value zero (0x000000) being reserved.
Count of items:: This 2 octet field contains the count of item on this filter dependency chains. Valid values are 0x0001 to 0xFFFF with the value of zero being reserved.
Item:: This (2 octets): filter sequence number on chain Valid values are 0x0001 to 0xFFFF with the value of zero being reserved.

The Extended IP Filters TLV has a type value of 2 with a variable length. The Extended IP Filters value field has the form shown in Figure 2-3 where:

FSv2 Extended Filters Group:: is a 1 octet field indicating the group of components supported. Three groups are defined in this document. Additional groups may be defined by registering the group in the FSv2 Extended IP Filter group registry (see IANA registry policy in section x.x), but those groups are outside the scope of this document.
Components+:: This field is a sequence of FSv2 Components with the format shown in figure 2-4.

+-------------------------------+ | Component Type (1 octet) | +-------------------------------+ | Component length (2 octets) | + ------------------------------+ | Component value (variable) | +-------------------------------+ Figure 2-4 – Component format Where:

Component type:: is a 1 octet specify the component type.
Component length:: is a 2 octet value specifying the component length.
Component value:: is a variable field defined per component.

The valid components for the Extended IP Filters defined by this specification are listed in table 2-X below. These components include the following:

IP Basic components:: Components 1-13 are defined in .
TTL: Filter on Time to Live in IPv4 packet or maximum hop limit in IPv6 packets.
SID function: SID in segment routing header (SRH) in the IPv6 packet.

Table 2-1 Components for Extended IP Filters SubTLV Extended IP Filters Components -type for IP Extended Filters version 2 -------- ---------------------------------- 0 - TTL 1 - IP Destination prefix 2 - IP Source prefix 3 – IPv4 Protocol od IPv6 Upper Layer Protocol 4 – Port 5 – Destination Port 6 – Source Port 7 – ICMPv4 type or ICMPv6 type 8 – ICMPv4 code or ICMPv6 code 9 – TCP Flags 10 – Packet length 11 – DSCP 12 – Fragment 13 – Flow Label 14 - TTL 15 - Reserved 16 - SID in Routing IPv6 Header

Three groups are defined for Extended IP Filters:

FSv1:: comprised of FSv2 components 1-13 (see Table 3-1)
FSv1 with TTL: compromised of FSv2 components 0-14 where TTL has component values 0 and 14 (see Table 3-2).
SR (Segment Routing): comprised of FSv2 components 0-17 were TTL has the component value of 0 and 14 (see Table 3-3).

Table 2-2 FSv1 Component Group (0x00) SubTLV Extended IP Filters Components -type for IP Extended Filters version 1 -------- ---------------------------------- 1 - IP Destination prefix 2 - IP Source prefix 3 – IPv4 Protocol or IPv6 Upper Layer Protocol 4 – Port 5 – Destination Port 6 – Source Port 7 – ICMPv4 type or ICMPv6 type 8 – ICMPv4 code or ICMPv6 code 9 – TCP Flags 10 – Packet length 11 – DSCP 12 – Fragment 13 – Flow Label

Table 2-3 FSv1 + TTL Component Group (0x01) SubTLV Extended IP Filters Components -type for IP Extended Filters version 1 -------- ---------------------------------- 0 - TTL 1 - IP Destination prefix 2 - IP Source prefix 3 – IPv4 Protocol or IPv6 Upper Layer Protocol 4 – Port 5 – Destination Port 6 – Source Port 7 – ICMPv4 type or ICMPv6 type 8 – ICMPv4 code or ICMPv6 code 9 – TCP Flags 10 – Packet length 11 – DSCP 12 – Fragment 13 – Flow Label 14 - TTL

Table 2-4 Segment Routing Group (0x02) SubTLV Extended IP Filters Components -type for IP Extended Filters version 2 -------- ---------------------------------- 0 - TTL 1 - IP Destination prefix 2 - IP Source prefix 3 – IPv4 Protocol od IPv6 Upper Layer Protocol 4 – Port 5 – Destination Port 6 – Source Port 7 – ICMPv4 type or ICMPv6 type 8 – ICMPv4 code or ICMPv6 code 9 – TCP Flags 10 – Packet length 11 – DSCP 12 – Fragment 13 – Flow Label 14 - TTL 15 - Reserved 16 - SID in Routing IPv6 Header

Table 2-5 Extended IP Component Ranges Sub-TLV range Definition ------------- ------------- 1-13 V1 filters 14-63 IP Extended Filters

The transmission of TLVs within a FSV2 NLRI SHOULD be sent via ascending user order. Within a single user order, the TLVs should be ordered by FSv2 Filter type. The FSv2 Filter types which MUST be supported for the Extended IP Filter support are Filter Type IP Basic (type = 1) and Filter Type Extended IP Filters (type = 2). Other FSv2 Filter types MAY be supported, but the support of those filter types is outside the scope of this document. Within a single user order number and the same IP Basic Filter Type, the components should be ordered by ascending numerical order of the component type. Within a single user order number and the same Extended IP Basic Type, the components should also be ordered by ascending component numbers. The Extended IP Filters version number simply indicates which components are required to be supported per version. Within a single user order and a single component number, the order of the filters is defined by the component. For example, if the component types are the same, then the value fields are compared as defined in , and . The filters MUST be stored with the value fields in ascending order. NLRIs having TLVs which do not follow the above ordering rules MUST be considered as malformed by a BGP FSv2 propagator. This rule prevents any ambiguities that arise 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"" .

Summary:: One line title summary
Component type:: The numerical value for component type. If the component value has not been assigned by IANA, this value should be in the form TBDx where x is a number (1..N).
Description:: Description of what component does.
What field component targets in IPv4 packet:: The specific field or fields the compnent filters. If the field filter is in the IPv6 packet, then this field is left (n/a).
What field Filter targets in IPv6 packet:: The specific field or fields the compnent filters. If the field filter is in the IPv4 packet, then this field is left (n/a).
Length:: Describe the length or possible lengths of this field.
Encoding of Component Value field: This is the encoding of the value in FSv2 NLRI. The best descriptions combine a diagram plus a description.
Ordering within component:: The mechanism to order if multiple components of the same type occur.
conflicts with other filters:: Describe what other filters this component could interfere with.
Example encoding:: Provide one simple example of the encoding of a filter for the component.
references:: earlier documents which defined this filter.

Summary:: Defines matches for 8-bit (1 octet) TTL field in IPv4 header and 8-bit (1 octet) in IPv6 header Hop limit.
Component Type:: 0 (0x00) and 14 (0x0E). Component type of zero (0x00) places the TTL (IPv4) or Hop limit (IPv6) filter prior to any other component test. Component ID value of 14 (0x0E) places the TTL (IPv4)/Hop limit (IPv6) filter after all IP Basic Filters.
Description:: This component filters IPv4 packets on a certain range of values for TTL for IPv4 packets or a range of avalues for Hop Limit for IPv6 packets.
What field Filter targets in IPv4 packet:: TTL field
What field Filter targets in IPv6 packet:: Hop Limit field
Length:: variable with valid values 2-N in increments of 2 octets.
Encoding of Component:

TTL Component Value encoding <[numeric_op, value]+> Figure 3-1 where:

numeric_op:: 1 octet field can express less than, greater than, or equal. The field numeric_op is defined in . This is the same format as the numeric-op for FSv1 components.
value:: is a 1 octet value for TTL for IPv4 packets and Hop limit for IPv6.

ordering of components:: by full value of number_op concatenated with value
conflict:: none
reference:: draft-bergeon-flowspec-ttl-match-00.txt

Summary:

IPv6 Service Identifier (SRv6 SID) Filter

Component type:

16 (0x10)

Description:

Filters the SRv6 SEgment Identifier in an IPv6 address associated the Segment Routing Header (SRH) ().

What field targets in IPv6 Packet:

Segment Routing Header (SRH)

SID in SRH:: defines SRv6 Segment Identifier (SID) as an IPv6 address explicitly associated with the segment. defines the SID format as: "LOC:FUNCT:ARG" where: locator (LOC) is encoded in the L most significant bits of the SID, followed by F bits of function (FUNCT), and A bits of arguments (ARG).

Length

The total of three lengths (i.e., LOC length + FUNCT length + ARG length) MUST NOT be greater than 128. If it is greater than 128, an error occurs and it is treated as a withdrawal [RFC7606] and [RFC4760]. The length of the value field depends on the field type and is the length of the SID parts being matched (see Table 3, Figure 3-6) in bytes, rounded up if that length is not a multiple of 8.

Encoding FSv2 Component Value:

This component is expressed as as a list of filter match conditions where a match is expressed as a bit match for some parts of SID (LOC, FUNCT, ARG) or the whole SID.

+------------------+-------------------+ | type (1 octet) | Loc-Len (1 octet) | +------------------+-------------------+ | FUNCT-len (octet)| ARG -len (1 octet)} +------------------+-------------------+ sequence of +--------------------------------------+ | op (1 octet) | value (variable | +------------------+-------------------+ [type, LOC-Len, FUNCT-Len, ARG-Len, [op, value]+] Figure 3-2 where: type (1 octet): one type octet determining type of match. The only valid value is 0x00 for Parts of SID. LOC-Len (1 octet): This indicates the length in bits of LOC in SID. FUNCT-Len (1 octet): This indicates the length in bits of FUNCT in SID. ARG-Len (1 octet): This indicates the length in bits of ARG in SID. [op, value]+: This contains a list of {operator, value} pairs that are used to match some parts of SID.

The operator (op) byte:

is encoded as:

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

where:

the behavior of each operator bit has clear similarity with that of [RFC8955]'s Numeric Operator field.

e (end-of-list bit):: Set in the last {op, value} pair in the sequence.
a - AND bit:: If unset, the previous term is logically ORed with the current one. If set, the operation is a logical AND. It should be unset in the first operator byte of a sequence. The AND operator has higher priority than OR for the purposes of evaluating logical expressions.

field type:

3 bits with the following meanings:

000:: SID's LOC
001:: SID's FUNCT
010:: SID's ARG
011:: SID's LOC:FUNCT (the concatenation of the LOC and FUNCTION fields)
100:: SID's FUNCT:ARG (the concatenation of the FUNCTION and ARG fields)
101:: SID's LOC:FUNCT:ARG (the concatenation of the FUNCTION and ARG fields)
Note:: For an unknown field type, Error Handling is to "treat as withdrawal" [RFC7606] and [RFC4760].

lt:

less than comparison between data' and value'.

gt:

greater than comparison between data' and value'.

eq:

equality between data' and value'.

use of lt,gt, and eq:

The data' and value' used in lt, gt and eq are indicated by the field type in an operator and the value field following the operator.

------------------ SID, 128 bits ---------------- / \ +-----------+-----------+-----------+----------------+ | LOC | FUNCT | ARG | ... | +-----------+-----------+-----------+----------------+ \ / \ / \ / \ / j bits k bits m bits 128-j-k-m bits \ / LOC:FUNCT, j+k bits \ / FUNCT:ARG, k+m bits \ / -- LOC:FUNCT:ARG, j+k+m bits – Figure 3-4

Dependency between components:

TBD

conflicts between components:

TBD

Examples in:

TBD

reference:

This section provides suggested templates for existing proposals for components and Extended IP Filter Groups. This section will be deleted prior to publication, and the proposals moved to individual drafts.

Summary:

Network Resource Partition ID Component

Description:

This filters an Option in the Next-Hop-Options header in IPv6 packet (, section 4). A Network Resource Partition (NRP) option carries around the network resource partition information (NRP) in the Hop-by-Hop options header (). This IPv6 Extension head has:

Flags (flags):: This is a 8 bit flag field in a single octet. One bit, "S" defined in most significant bit. The S stands for strict match of NRP ID field. The NRP Flags field is filtered for by the FSv2 component Flags field.
Context type (CT):: 1 octet field indicating the semantics and length of NRP-ID field. The value of CT=0 indicates a 4-octet NRP ID, F bits of function (FUNCT), and A bits of arguments (ARG).

What filtering in IPv6 Packet:

IPv6 Hop-by-Hop Options Header ()

FSv2 NRP ID Component value field:

Defines match for NRP ID in the NRP option of Hop-by-Hop Header. This FSv2 component has 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NRP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4-1: NRP FSv2 Component where:

Flags:

This field is 2 octets with only the most signficant bit defined as Global Bit (g).

Global bit (g):: When set, it indicates the NRP ID to be matched with a globally unique NRP ID. Otherwise, the NRP-ID is to be a domain significant NRP ID. The global NRP ID has been coordinated among these domains.

Reserved:

This a 2-octet field reserved for future use. It SHOULD be set to zero on transmission and MUST be ignored on receipt.

NRP ID:

This is a 4-octet identifier which is used to identify an NRP

Interactions with:

None

reference:

Summary:: IP Payload filter
Description:: Flexible Deep packet filters
IP Packet filtering:: IPv4 and/or IPv6
What filtering in packet:: Data in header or within the payload.
Encoding:: The filter has an offset to filter data from the point specified in the "offset-type field" for using a filter of specific length (content-length) with a specific pattern (content). The type of packet IPv4 or IPv6 is specified in Type of IP packet. The structure of the component is:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | component Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PType | Otype | offset (offset-value) | content length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | content | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4-2: FSv2 IP Payload Match Component
Where the Ptype - 4 bit field indicating the packet type via AFI (IPv4 or IPv6) IPv4 = 1 IPv6 = 2 Otype - 4 bit field indicating the offset type where 0 = IP header 1 = IP header data 2 = Data within TCP/UDP offset - is number of bytes to the payload from the point defined by Ptype and Otype. content length - length of the content. content - content filter field to match (significant field bit zero).
Ordering within component:: (TBD)
Interacts with components:: (TBD)
reference:

Summary:: Filter on Group ID
Description:: Flexible filters on group identifiers
IP Packet filtering:: IPv4 or IPv6
What filtering:: Group ID specified sub-type
What Filtering in Packet:: The filter looks for a specific type of group ID within either the IPv4 or IPv6 packet header.
Encoding of component:: The structure of the component is the following
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Type | Offset type | Group type | SubGroup type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset value | GMask length | SG Mask length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group ID value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Group Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4-3: FSv2 IP Payload Match Component
Where the Packet type - 8 bit field indicating the packet type IPv4 = 1 IPv6 = 2 Offset type - 4 bit field indicating the offset type where 0 = IP header 1 = IP header data 2 = Data within TCP/UDP offset - is number of bytes to the payload from the point defined by Ptype and Otype. Group type - 1 octet field indicating the type of group ID 0 = Reserved 1 = Indirection ID 2 = Interface group 3 = CATS ID 4 = SAV ID 5 = APN ID Sub-Group type - Sub group within filters. 0 = Reserved 1 = data traffic (Inbound/outbound) 1 = data traffic Inbound only 2 = data traffic outbound only Group Mask - (variable) Group field mask Group ID value - (variable) Group ID value to match Sub Group Mask - (variable) Sub-Group Mask Sub-Group Value - (variable) Sub-Group value to match on
Ordering within component:: TBD
Dependency between components:: TBD
Donflicts with other components:: (TBD)
Reference:: TBD (just a sample)
Note:: In addition, the Group will need to define a registries for Group types and sub-group types.

Three new Extended IP filter groups could be created from these filters for SRv6, SRv6+Payload, SRv6 + groups. Tables 3-x, 3-x, and 3-y show these grouping. These groups are simply suggests for the proposed individual drafts to consider.

Table 4-1 SR + Payload Filters SubTLV Extended IP Filters Components -type for IP Extended Filters version 2 -------- ---------------------------------- 0 - TTL 1 - IP Destination prefix 2 - IP Source prefix 3 – IPv4 Protocol od IPv6 Upper Layer Protocol 4 – Port 5 – Destination Port 6 – Source Port 7 – ICMPv4 type or ICMPv6 type 8 – ICMPv4 code or ICMPv6 code 9 – TCP Flags 10 – Packet length 11 – DSCP 12 – Fragment 13 – Flow Label 14 - TTL 15 - Reserved 16 - SID in Routing IPv6 Header 17 - NRP-ID in Hop-by-Hop IPv6 Header 18 - Payload

Table 4-2 SR + Payloads + Group Filters SubTLV Extended IP Filters Components -type for IP Extended Filters version 2 -------- ---------------------------------- 0 - TTL 1 - IP Destination prefix 2 - IP Source prefix 3 – IPv4 Protocol od IPv6 Upper Layer Protocol 4 – Port 5 – Destination Port 6 – Source Port 7 – ICMPv4 type or ICMPv6 type 8 – ICMPv4 code or ICMPv6 code 9 – TCP Flags 10 – Packet length 11 – DSCP 12 – Fragment 13 – Flow Label 14 - TTL 15 - Reserved 16 - SID in Routing IPv6 Header 17 - NRP-ID in Hop-by-Hop IPv6 Header 18 - Payload 19 - Group filters

Validation of the FSv2 NLRI follows the rules from section 4.1 of . For ease of reference to this validation procedure, the implementer might consider the following facts:

Extended IP filters -: are passed as either IPv4 (AFI=1, SAFI=TBD1), IPv6 (AFI=2, SAFI=TBD1), IPv4 VPN (AFI=1, SAFI=TBD2), IPv6 VPN (AFI=2, SAFI=TBD2). or (AFI=2) SAFI=TBD1 or SAFI=TBD2.
IP Extended filters sent in SAFI=TBD1 -: are validated against SAFI=1. To be specific, (AFI=1, SAFI=TBD1) is validated against (AFI=1, SAFI=1), and (AFI=2, SAFI=TBD1) is validasted against (AFI=2, SAFI=1).
IP Extended filters sent in SAFI=TBD2 -: are validated against SAFI=128. To be specific, (AFI=1, SAFI=TBD2) is validated against (AFI=1, SAFI=128) AND (AFI=2, SAFI=TBD2) is validated against (AFI=2, SAFI=128).

Validation of the FSv2 NLRI follows the rules from section 4.2 of apply to the FSV2 NLRI filters. For ease of reference to this section, implementers might consider the following facts:

FSv2 defines a Rule-0 for 0/0 with "permit-all" action. -: By default, FSv2 (and FSv1) restrict the flow from permit all. By configuration, Rule-0 could be set to 0/0 with "permit-none" and filters could have the benefit of allowing traffic. If this configuration knob is set, then it MUST be used in a limited Domain of cooperating networks.
FSv2 rules are ordered by ascending user order number, FSv2 Filter type, FSv2 component type, and FSv2 component value.: This ordering rules means that multiple FSv2 filter rules with the same user order number of ordered by ascending FSv2 filter types (IP Basic (0x01) and Extended IP Filters (0x02)). If the FSv2 filter has the same user order and Filter type, then the order is by ascending FSv2 component type numbers. Finally, if FSv2 filters have the same user order, Flter type, component type, then the filter is ordered by the component value.
Order is deterministic, but arbitrary.: Users may use the user ordering and dependency chain to establish more complex relationships.

The following two error handling rules stated in Section 4.1.3 of must be followed by all BGP speakers:

1) FSv2 NLRI having TLV which do not have the correct length or syntax: must be considered MALFORMED. Syntax is defined as having each field within NLRI header (order, dependent filters chain and within the FSv2 TLV (IP Basic TLV or Extended TLV) header, and each component. Any MALFORMED FSv2 NLRI is handled as "TREAT AS WITHDRAW" per .
2) Any FSV2 NLRI which do not follow the ordering rules: described in section 4 for filters is considered MALFORMED.

Actions are transmitted on Extended Communities (EC) for FSv2 basic actions (FSv2-EC) or BGP Community path attribute (CPA) with FSv2 TLV (FSv2-CPA). The following rules MUST be followed by the FSv2 actions:

If BGP Community Path Attribute is not supported, then:: FSv2-EC MUST be ordered by FSv2 default order (see ) if one of the two conditions is not present: Implement configuration knob that implementation specific order is set Action Chain Order (ACO) FSV2-EC is attached with the Action dependency set to implementation specific
If a BGP Community Path Attribute with a FSv2 TLV (FSv2-CPA)is supported and attached in an invalid form, then:: the FSv2-CPA is ignored and not forwarded.
If BGP Community Path Attribute with a FSv2 TLV (FSv2-CPA) is supported and a valid FSv2-CPA is attached, then:: the FSv2-CPA takes precedence over FSv2-EC. The BGP Community Path attribute allows for user ordering with user order values of [1-N]. By default, the FSv2-EC follow the FSv2-CP actions (N+1) with all FSv2-EC on the same user order number. Early deployments of FSv2-CPA may want to reverse this order (first FSv2-EC, then BGP Community Path attribute). If so, FSv2-EC should be defined as [action order 0] by configuration knob.

FSv1 is a key part of many existing networks. The introduction of FSv2 is expected to be a phased process. where FSv1 is replaced slowly. One potential way this might occur is the following:

FSv2 IP basic replaces FSv1 -: A FSv2 implementation may simply configure FSv2 with the same IP Basic components as used in FSv1, and a user order of 1 for FSv2. FSv1 would be configured with a default user order of 10. The same Extended Communities are passed plus an ACO community (Generic Transitive Extended Community (0x01)) with ACO-Dependency of 0x0 (implementation specific) and AC-FAilure (0x00).
FSv2 IP basic with default Action order: ACO FSv2-EC used when FSv2-EC action order is needed to detect conflicts in actions in remote BGP peers.
FSv2 IP basic with flexible user order: After the implementations are solid, it is expected that networks will use FSv2 user ordering to provide flexible ordering.
FSv2 Extended IP Filters with no dependency chain are deployed.: The dependency chain field can be left as zero for any deployment of FSv2 Filter NLRI.
FSv2 MPLS Filters with no dependency chain are deployed.: The default ordering of the filters with the same user order number would be IP Basic Filters (0x01), Extended IP Filters (0x02), and MPLS Filters (0x03). If MPLS filters need to be done first, then the user order of MPLS would need to be lower than Extended IP filters. Please note that SRv6 headers are Extended IP Filters so SRv6 takes precedence over MPLS label filters.

This section complies with .

IANA is requested to indicate [this draft] as a reference on the following assignments in the Flow Specification Component Types Registry:

ID Name Reference ---- ----------- ----------------- 0 TTL [this document] 14 TTL [this document] 15 Reserved [this document] 16 Partial SID [this document] 17 NRP ID [this document]

IANA is requested to create the following a registry for extended IP Filters Group with the following values. Registry type is "IETF-Consensus" for values 0x04 to 0xFF. Registry type is "FCFS" for values 0x100 to 0x1FF.

ID Group Name Valid FSV2 component values Reference --- ----------- ---------------- ----------------- 0 FSv1 0-13 [this document] 1 FSv1 + TTL 0-14 [this document] 2 SRv6 0-16 [this document] Values 0x04 - 0xFF (255) - Assigned via IETF Consensus Values 0x100 - 0x1FF (300-511) - Expert review Values 0x200 - 0x2FF (512-7670 - FCFS A template for requesting the IP Filters group assignment is given below.

Name:: Provide a short name (10 characters, maximum)
Summary:: One line title summary
Component IDs included:: The numerical value for component ID type.
Type of Group Assignment:: This should either be IETF Consensus, Expert review or FCFS.
Document reference:: document that defines group
Contact:: Person making request

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.