BGP Flow Specification Version 2

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 remains an WG draft, but the content will be split out into functions that implementers can manage. Section 1.3 contains the list of documents resulting from the split of the original FSv2 documents. FSv2 defines new user-ordered filters that will be used with the IPv4 (AFI=1) and IPv6 (AFI=2) 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended). This draft specifies defines extensions to the FSv2 Basic IP package to support additional IP filters for IP packet and payload. The filters are passed in the Extended IP Filters (type 2) of the subTLVs. This filter form contains a filter version number so filters can be added easily. BGP Flow Specification version 1 (FSv1) as defined in , , and specified 2 SAFIs (133, 134) to be used with IPv4 AFI (AFI = 1) and IPv6 AFI (AFI=2). FSv2 specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of traffic match filters for user-ordered traffic match actions encoded in Communities (Wide or Extended). The first SAFI (TBD1) will be used for IP forwarding, and the second SAFI (TBD2) will be used with VPNs. The supported AFI/SAFI combinations in FSv2 are: 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. FSv2 specifies allows new IP filters to be used with the IPv4 (AFI=1) and IPv6 (AFI=2). FSv2 for Basic IP suggests these new filters are added in a component called "Extended IP Filters . provides a summary of the additional IP filters which have been adopted by the IDR WG or proposed to the IDR WG. It is anticipated that the filters will be added in groups as needed by applications. The original FSV2 work proposed an user-ordered of traffic match actions encoded in the Community Path Attribute. This document proposes: a specification order for IP actions in Extended Communities, and a user ordering for IP Actions in the Community path Attribute. Section 2 contains a description of the format of the FSv2 actions in Extended Communities and Wide Communities. Since Extended Communities can be attached to a FSv2 NLRI with filters, it is possible that the Extended Communities conflict with each other. Section 3 lists the FSv1 actions that conflict with one another if attached to the same filter. This document proposes that Extended Community actions attached to FSv2 NLRI use a pre-defined order that occurs after the User defined orders. The predefined order for Extended Communities in FSv2 NLRI would be set by the action type value (see section 6.3). For example, if the user-actions range from 1-1000, the Extended Community order would start after those actions. Sections 4 and 5 provide a short description of new actions proposed for FSv2. Section 4 provides a description of the Action Chain Ordering proposed for the FSv2 for Basic IP (. Section 5 lists the potential new actions from FSv2 actions described in IDR WG drafts or proposed as individual drafts. Sections 6, 7, and 8 provide information on validation, ordering, and error handling of FSv2 actions. Section 6 describes validation of actions and ordering of actions (user ordered and default). Section 7 describes error handling for FSv2 actions. Section 8 provides an example for ordering of actions. Section 9 provides details on IANA considerations

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. DDOs - Distributed Denial of Service Ephemeral state - state which does not survive the reboot of a software module, or a hardware reboot. Ephemeral state can be ephemeral configuration state or operational state. FSv1 - Flow Specification version 1 [RFC8955] [RFC8956] FSv2 - Flow Specification version 2 (this document) NETCONF - The Network Configuration Protocol . 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 full FSV2 information is contained in . Feedback from the implementers indicate that the Flow Specification v2 needs to broken into drafts based on the use cases the technology supports. These include IPv4/IPv6 IP Basic Filters for DDOS, IPv4/IPv6 filters beyond DDOS, BGP/MPLS IPv4 VPN, BGP/MPLS IPv6 VPN, BGP/MPLS L2VPN, Segment routing (SRMPLS, SRv6), SFC, SFC VPN, L2, L2 VPNs, and tunneled traffic (e.g., nv03 WG tunnels). The following is the list of planned drafts: FSv2 IP Basic () FSv2 More IP Filters () FSv2 More IP Actions () FSv2 Non-IP Filters (draft-hares-idr-fsv2-non-ip-Filters) FSv2 Non-IP Actions (draft-hares-idr-fsv2-non-ip-actions) has a description of each draft. The original FSV2 information is contained in .

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. FSv2 IP Basic proposes that Extended Community actions attached to FSv2 NLRI use a pre-defined order that occurs after the User defined orders. The predefined order for Extended Communities in FSv2 NLRI would be set by the action type value (see section 6.3). For example, if the user-actions range from 1-1000, the Extended Community order would start after those actions. The Community attribute describes an attribute with flexible format for specifying community information. This section first describes the following Information related to FSv2 Actions in Extended Communities: Generic Transitive Extended Communities for FSv2 Actions (FS-TG-EC) Transitive Extended Communities for redirect. This includes: (Generalized redirection ID with Sequencing and copy) Redirect plus Copy bit Transitive IPv6-Address Extended Community formats for FSv2 actions

The FSv2 actions encoded in Generic Transitive Communities inherit the FSv1 actions in Generic Transitive Communities. The Extended Community encodes the Flow Specification actions in the Extended Community format as Generic Transitive Extended Communities per per , , and . The format of the these actions can be: where the Sub-Types are defined in the Generic Transitive Extended Community Sub-Types registry. where the Sub-Types are defined in the Generic Transitive Extended Community Part 2 Sub-Types registry. where the Sub-Types defined in the Generic Transitive Extended Community Part 3 Sub-Types registry. where the Sub-Types defined in the Transitive Opaque Extended Community Sub-Types" registry.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type high | Type low(*) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (6 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-1

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

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

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

Table 2-4: Traffic Action bits Bit Name Name Reference ===== =============== ==== ========== 47 Terminal Action TAct [RFC8955] 46 Sample Samp [RFC8955] 45 Copy Copy [this document] 44 Drop drop [this document]

FSv2 needs to refine the following Transitive Extended Communities that are not "Transitive Generic Communities" to a specific set of functions. These features provide overlapping functions. While some of these features are implemented, these actions should be be reviewed. There are three types of functions: Active filters on interfaces in group for inbound or outbound data traffic Redirect to an IP address. Optionally perform a traffic action (copy) Redirect to an Indirection ID of a specific type. Optionally perform a traffic action (copy).

Table 2-5 Transitive Extended Community types (T-EC-types) sub-type FSv1 Description Name Reference ======== ================== ===== ================= 0x07 FS Interface set Ifset [IDR-WG-ifset] 0x08 FS Redirect/ RIPv4 [IDR-WG-redirect-ip] Mirror 0x09 FS Redirect to Indirection-id RGID [IDR-WG-redirect-iid] [IDR-WG-ifset] [IDR-WG-redirect-ip] [IDR-WG-redirect-iid]

The IPv6 Extended Community encodes the Flow Specification actions in the Extended Community format () in the transitive opaque format (See , , and )

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-type | Global Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | Global Administrator (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Administrator (cont.) | Local Administrator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2-2 The 20 octets of value are given in the following format: Global Administrator: IPv6 address assigned by Internet Registry Local Administrator: 2 bytes of Local Administrator

Table 2-6 transitive IPv6-Address-Specific Actions Value Description Name Reference ===== ======================= ===== ========== 0x01 Flow Spec Action Chain ACO [This document] 0x0C Flow Spec redirect-v6-flag RD6F [IDR-WG-RD6f] 0x0D Flow Spec rt-redirect RDv6 ]RFC8956] IPv6 format Figure 3-16 [RFC8956] - IDR-WG-RD6F -

The user-ordered FSv2 Actions use the Communities Path Attribute defined in . The Community BGP Path attribute is a flexible Community container which allows different formats for different community applications. The FSv2 Community Type ([FSv2-CA], type=TBD4) is only used for FSv2 user-ordered actions. If both the Extended Community FSv2 Actions (FSv2-EC) and the FSv2 Community Attribute actions are specified (FSv2-CA) then the default preference will be the FSv2-CA prior to the FSv2-EC. This preference may be changed based on a configuration knob. However, this configuration MUST be consistent within an Autonomous System or a group of Autonomous Systems where both the FSv2-CA and FSv2-EC are deployed.

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

where: Type = the type of community (Type 1 or Type 2) Flag = an octet of bits with only two bit that can be set T = 1 - Transitive across AS boundaries T = 0 - Non-Transitive across AS boundaries C = 1 - Transitive across Confederation boundaries C = 0 - Non-Transitive across Confederation boundaries figure 2-4 The FSv2 Action TLVs have the following format:

Common Header for Action TLVs 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Action order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dependency chain ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence of Action SubTLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each Action SubTLV has the format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ figure 2-5 where: User Action Order - 4 octet field indication user defined action order. Dependency chain ID - 4 octet field indicating dependency chain identification. (Editor's note: Dependency chain needs further discussion from WG.} Sequence of Action SubTLVs - The type-length-value fields specified per Action type.

Table 3-1: Conflicts between FSv2 Transitive Generic IPv4 actions IPv4 Extended Communities (Type 0x80) Value Name Conflicts with ===== ===== ======================== 0x01 ACO none 0x06 TRB TRP 0x07 TAIS duplication also done in RDIP, RIPv4, RGID 0x08 RDIP redirection done in RIPv4, RGID copy done in TAIS 0x09 TMDS none 0x0C TRP TRB 0xOD SFCC none

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

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. The IDR WG draft contains the long-term plan for FSv2 filters with actions. Any new Actions for FSv2 should be specified in both the Extended Community format and the Community Path Attribute formatt. The FSv2 for Basic IP will support existing IPv4 from , and existing IPv6 actions from and one additional feature for action chain ordering (ACO). An action chain for FSv2 Extended Community actions is defined as a series of Extended Communities which are attached to a set of filters. The action chain ordering (ACO)action provides a set of flags that define a clear action if failure occurs. One of the issues with FSv1 is the lack of a clear definition on what happens if multiple actions interact. The existence of the Action chain ordering action enforces that the actions will have a deterministic outcome during failures. The AC-Failure types are: 0x00 – default – stop on failure 0x01 – continue on failure (best effort on actions) 0x02 – conditional stop on failure (depends on AC-Failure-value/policy) 0x03 – rollback do all or nothing (depends on AC-Failure-value/policy) Editors note: The following options for encoding ACO exist. redefine bits in Traffic Action subtype create a new Extended Community

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type high | Type low(01) |AC-failure-type| AC-Failure | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC-Failure-value (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4-1 SubTLV: 0x01 Length: 6 octets Value: AC-dependence - 1 octet byte of flag regarding dependency AC-failure-type – 1 octet byte that determines the action on failure AC-failure-value – variable depending on AC-failure-type. Actions may succeed or fail and an Action chain must deal with it. The default value stored for an action chain that does not have this action chain is “stop on failure”. where: AC-Failure types are: 0x00 – default – stop on failure 0x01 – continue on failure (best effort on actions) 0x02 – conditional stop on failure – depending on AC-Failure-value 0x03 – rollback – do all or nothing - depending in AC-Failure-value AC-Failure values: TBD Interactions with other actions: Interactions with all other Actions Ordering within Action type: By AC-Failure type

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type high | Type low(07) |traffic action field (zero) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AC-Failure-value (cont.) | ACO |S|T| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ figure 4-2 Where ACO - is the Action Chain failure types (0x00 to 0x03) 00 - stop on failure 01 - continue on failure 02 - conditional stop on failure (by policy) 03 - rollback on failure (with policy) S - Sample flag T - Terminal action

Table 5-1 shows the actions for Extended-Communities FSv2 actions from IDR RFCs, IDR WG drafts and drafts proposed to IDR. The link between the short names and the IETF draft names is shown in Table 5-2. Table 5-3 has FSv2 actions proposed for IPv6. The FSv2 Extended Communities actions (FSv2-EC actions) would take a default ordering based on the numerical order of the action id (act-id). For example, ACO (act-id = 1) would be processed before Traffic Actions per interface group (act-id = 3). A match on an IP Filters can request a non-IP action. Table 5-3 gives a list of Non-IP functions defined for FSv2-EC action. The order of processing the non-IP action is done by the action id (act-id). FSv2 rules can link non-IP actions can be to IP filters. For example, the SFC filters for IP link an SFC classifier action (name: TISFC, Action-id = 31). Table 5-4 contains FSv2 actions for IPv6. The size of the IPv6 fields require a unique space for some redirect actions in Extended Communities. (Editor's note: IPv6 Extended Community actions do not have to be unique in the TLV formats in the Community Attribute.)

Table 5-1 All IP Actions in Extended Communities act-id Name Description Document ====== ===== ================ ====================== 00 RSV Reserved [this document] 01 ACO action chain order [this document] 02 TBA Unassigned [this document] 03 TAIS traffic actions [IDR-FSv2-ifset] per interface group 04 TBA to be assigned [this document] 05 TBA to be assigned [this document] 06 TRB traffic rate [RFC8955] limited by bytes 07 TA traffic action [RFC8955] (terminal/sample) 08 RDIP Redirect IPv4 [IDR-FSv2-RDP-ip] 09 TM Mark DSCP value {RFC8955] 10 TBA Unassigned [this document] 11 TBA Unassigned [this document] 12 TRP traffic rate [RFC8955] limit by packet 13 TISFC SFC Classifier [RFC9015] 14 RDIID redirect to [IDR-FSv2-RDPIID] Indirection-id [PD-FSv2-mobility] move from 0x00) 15 TBA Unassigned [this document] 16 TBA Unassigned [this document] 17 NRP-ID Encapsulate [IDR-net-slice-ts] NRP-ID value 18 GrP-ID Set Group ID [PD-peng-group-sub] Figure 3-15

Table 5-2 Short Names to IETF documents Short-name Filename ================= =============================== IDR-FSv2 draft-ietf-idr-flowspec-v2-04 IDR-FSv2-ifset draft-ietf-idr-flowspec-interfaceset-05 IDR-FSv2-linkbw draft-ietf-idr-linkbandwidth IDR-FSv2-RDP-ip draft-ietf-idr-flowspec-redirect-ip-02 IDR-FSv2-RDPIID draft-ietf-idr-flowspec-redirect-path IDR-net-slice-ts draft-ietf-idr-flowspec-network-slide-ts-02 IDR-FSv2-L2VPN draft-ietf-idr-flowspec-l2vpn-17 IDR-FSv2-mpls draft-ietf-idr-fsv2-mpls-actions IDR-FSv2-SR draft-ietf-idr-fsv2-sr-actions PD-FSv2-mobility draft-dmc-flowspec-tn-aware-mobility PD-peng-group-sub draft-peng-idr-apn-bgp-flowspec-00 PD-redirect-IPv6 draft-ietf0-idr-path-redirect-12

Table 5-3 All Non-IP Actions in Extended Communities act-id Name Description Reference ====== ===== ================ ================ 31 TISFC SFC classifier II [RFC9015]- moved 32 MPLSLA MPLS label action [IDR-FSv2] [IDR-FSv2-mpls] 33 VLAN VLAN-Action (0x16) [ID-FSv2-L2VPN] 34 TPID TPID-Action (0x17) [ID-FSv2-LVPN] 24- TBA to be assigned 254 TBA to be assigned 255 reserved Figure 3-15

Table 5-4 IPv6 Extended Communities (Type 1) Value Description Name Reference ===== ======================= ===== ========== 0x01 Flow Spec Action Chain ACO [This document] 0x0C Flow Spec redirect-v6-flag RD6F [PD-redirect-IPv6] 0x0D Flow Spec rt-redirect RD6 [RFC8956] IPv6 format

The FSv2 Community Path Attribute could inherits the FSv2 Extended Community actions (FSv2-EC) with the same action identifiers (act-id) numbering. For each of the actions, a new form of the FSv2-EC would need to be defined. The next section is set-aside for definition of the FSv1 based attributes standardized in and >, and deployed FSv1 actions. New FSv2-EC must define both an Extended Community form and a Community Path Attribute form.

The following FSv2 Communjity Path Attributes created from FSv1 actions will be defined in this section: action chain order (ACO)(type = 01), traffic actions per interface group (TAIS) (type = 02), traffic rate limited by bytes (TRB (type = 06), traffic actions (TA) (type = 07), redirect IPv4 (RDIP) (type = 08), mark DSCP valiue (TM) (type = 09), traffic rate limit by packet (TRP)(type = 12), SFC Classifier (TISFC) (type = 13), Redirect to Indirection-ID (type=14), Encapsulate in NRP-ID (type = 17) Set Group ID (type = 18)

The current actions proposed for the FSv2 Community Path Attribute are are shown in Table 5-5. The

Table 5-5 All Actions Proposed for FSv2 Community Path Attribute act-id Name Description Document ====== ========= ============== ====================== TBD MatchSet Match and Set [IDR-rpd] (type = 03) attribute TBD MatchNoA Match and No [IDR-rpd] (type = 04) Advertise TBD DetLat Deterministic [PD-detnet-flowmap] ( Latency action (type = 37) TBD TSNMap Map flow to [PD-detnet-flowmap] TSN stream (type = 38) Table 5-6 File Names IDR-rpd - PD-detnet-flow-map -

The validation of FSv2 NLRI adheres to the combination of rules for general BGP FSv1 NLRI found in , , , and the specific additions made for SFC NLRI , and L2VPN NLRI . The precedence for FSv2 actions are described in this section rather than simply referring to the relevant portions of these RFCs. Validation only occurs after BGP UPDATE message reception and the FSv2 NLRI and the path attributes relating to FSv2 (Extended community and Wide Community) have been determined to be well-formed. Any MALFORMED FSv2 NRLI is handled as a “TREAT as WITHDRAW” .

FSv2 actions may specify actions using Extended Communities or the path attribute Community with the FSv2 format. The FSv2 actions in Extended Communities and Wide communities can be associated with large number of NLRIs. Actions may conflict, duplicate, or complement other actions. An example of conflict is the packet rate limiting by byte and by packet. An example of a duplicate is the request to copy or sample a packet under one of the redirect functions (RDIPv4, RDIPv6, RDIID, ) Each FSv2 actions in this document defines the potential conflicts or duplications. Specifications for new FSv2 actions outside of this specification MUST specify interactions or conflicts with any FSv2 actions (that appear in this specification or subsequent specifications). Well-formed syntactically correct actions should be linked to a filtering rule in the order the actions should be taken. If one action in the ordered list fails, the default procedure is for the action process for this rule to stop and flag the error via system management. By explicit configuration, the action processing may continue after errors. Implementations MAY wish to log the actions taken by FS actions (FSv1 or FSv2).

The ordering of precedence for these actions in the case are: Action user-order number zero is defined to have an Action type of “Set Action Chain operation” (ACO) that defines the default action chain process. user order (1 to N-1) Extended Community Actions {starting at N) By default, extended community actions are associated with default order number 32768 [0x8000] or a specific configured value for the FSv2 domain. Within the actions defined at the same order, the order is: Action ID (lowest to highest) If multiple Actions of the same value are define (e.g. Redirection to Indirection ID), the action must define the order. All Extended Community actions and Path Community attributes should be ordered in the same IP space.

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

FS Action Value Order (lowest value to highest) (lowest to highest) ================================ ============================== 0x01: ACO: Action chain operation Failure flag 0x02: TAIS:Traffic actions per AS, then Group-ID, then Action ID Interface group 0x03-0x05 to be assigned TBD 0x06: TRB: Traffic rate limit AS, then float value by bytes 0x07: TA: Traffic Action traffic action value 0x08: RDIP: Redirect to IP AS, then IP Address, then ID 0x09: TM: Traffic Marking DSCP value (lowest to highest) 0x0A: AL2: Associated L2 Info. TBD 0x0B: AET: Associated E-tree Info. TBD 0x0C: TRP: Traffic Rate limit AS, then float value by bytes 0x0D: RDIPv6: Traffic Redirect to IPv6 AS, IPv6 value, then local Admin 0x0E: TISFC: Traffic insertion to SFC SPI, then SI, the SFT 0xOF: Redirect to Indirection-ID ID-type, then Generalized-ID 0x10: MPLSLA: MPLS Label stack order, action, label, Exp 0x16 – VLAN action rewrite-actions, VALN1, VLAN2, PCP-DE1, PCP-DE2 0x17 – TPID action rewrite actions, TP-ID-1, TP-ID-2 Figure 6-1

The following two error handling rules must be followed by all BGP speakers which support FSv2: 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 above 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.

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

Use Case 1: Rate limit to 600 packets per second Description: The provider will support 600 packets per second All Packets sampled for reporting purposes and packet streams over 600 packets per second will be dropped. Suppose BGP Peer A has a a Wide Community action with user-defined order 10 with Traffic Sampling a Wide Community action with user-defined order 11 from AS 2020 that limits packet-based rate limit of 600 packets per second. an Extended Community from AS 2020 that does limits packet-based rate limit of 50 packets per second. The FSv2 data base would store the following action chain: at user-defined action order 10 A user action of type 7 (traffic action) with values of Sampling and logging. at user-defined action order 11 a user action type of 12 (packet-based rate limit) with values of AS 2020 and float value for 600 packets per second (pps) at user-defined action order 32768 (0x8000) with type 12 and values of A user action of type 12 with values of AS 2020 and float value of 50 packets/second. Normal action: The match on the traffic would cause a sample of the traffic (probably with packet rate saved in logging) followed by a rate limit to 600 pps. The Extended community action would further limit the rate to 50 packets per second. When does the action chain stop? The default process for the action chain is to stop on failure. If there is no failure, then all three actions would occur. This is probably not what the user wants. If there is failure at action 10 (sample and log), then there would be no rate limiting per packet (actions 11 and action 32768). If there is failure at action 11 (rate limit to packet 600), then there would be no rate limiting per packet (action 32768). The different options for Action chain ordering (ACO) have been worked on with NETCONF/RESTCONF configuration and actions.

Use case 2: Redirect traffic over limit to processing via SFC. Description: The normal function is for traffic over the limit to be forwarded for offline processing and reporting to a customer. Suppose we have the following 4 actions defined for a match: Sent Redirect to indirection ID (0x01) with user-defined match 2 attached in wide community, Traffic rate limit by bytes (0x07) with user-defined match 1 attached in wide community, Traffic sample (0x07) sent in extended community, and SF classifier Info (0x0E) sent in extended community. These 4 filters rate limit a potential DDoS attack by: a) redirect the packet to indirection ID (for slower speed processing), sample to local hardware, and forward the attack traffic via a SFC to a data collection box. The FSv2 action list for the match would look like this Action 0: Operation of action chain (0x01) (stop upon failure) Action 1: Traffic Rate limit by byte (0x07) Action 2: Redirect to Redirection ID (0x0F) Action 32768 (0x8000) Traffic Action (0x07) Sample Action 32768 (0x8000) SFC Classifier: (0xE) If the redirect to a redirection ID fails, then Traffic Sample and sending the data to an SFC classifier for forwarding via SFC will not happen. The traffic is limited, but not redirect away from the network and a sample sent to DDOS processing via a SFC classifier. Suppose the following 5 actions were defined for a FSV2 filter: Set Action Chain Operation (ACO) (0x01) to continue on failure (ox01) at user-order 2 attached in wide community, redirect to indirection ID (0x0F) at user-order 2 attached in wide community, traffic rate limit by bytes (0x07)with user-order 1 attached in wide community, Traffic sample (0x07) attached via extended community, and SFC classifier Info (0x0E) attached in extended community. The FSv2 action list for the match would look like this: Action 00: Operation of action chain (0x01) (stop upon failure) Action 01:Traffic Rate limit by byte (0x07) Action 02:Set Action Chain Operation (ACO) (0x01) (continue on failure) Action 02: Redirect to Redirection ID (0F) Action 32768 (0x8000): Traffic Action (0x07) Sample Action 32768 (0x8000): SFC classifier (0x0E) forward via SFC [to DDoS classifier] If the redirect to a redirection ID fails, the action chain will continue on to sample the data and enact SFC classifier actions.

This section complies with .

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

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

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

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

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.