idnits 2.17.00 (12 Aug 2021) /tmp/idnits62352/draft-ietf-idr-flowspec-v2-00.txt: -(2541): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 22 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1783 has weird spacing: '... Name form...' == Line 1797 has weird spacing: '... Name form...' == Line 1830 has weird spacing: '... octets leng...' == Line 1841 has weird spacing: '... Name form...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 11: reserved value - - This value is reserved and MUST not be sent in the packet. -- The document date (18 April 2022) is 26 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7091' is mentioned on line 894, but not defined == Missing Reference: '4-octet-AS' is mentioned on line 1790, but not defined == Missing Reference: 'TBD6' is mentioned on line 1333, but not defined == Missing Reference: '4-byte-AS' is mentioned on line 1836, but not defined == Missing Reference: 'IEEE.754.185' is mentioned on line 1470, but not defined == Missing Reference: '4-octet-as' is mentioned on line 1790, but not defined == Missing Reference: 'S-ID' is mentioned on line 1570, but not defined == Missing Reference: 'C' is mentioned on line 1575, but not defined == Missing Reference: '2-byte-AS' is mentioned on line 1831, but not defined == Missing Reference: 'AS-2-octets' is mentioned on line 1810, but not defined == Missing Reference: 'IPv4-address' is mentioned on line 1811, but not defined == Missing Reference: 'AS-4-octets' is mentioned on line 1818, but not defined == Missing Reference: 'ID-2-octets' is mentioned on line 1819, but not defined == Missing Reference: 'TBD' is mentioned on line 2004, but not defined == Missing Reference: 'RFC4456' is mentioned on line 2191, but not defined == Missing Reference: '0x8000' is mentioned on line 2354, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-idr-flowspec-l2vpn-18 == Outdated reference: A later version (-07) exists of draft-ietf-idr-wide-bgp-communities-06 Summary: 0 errors (**), 0 flaws (~~), 25 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Hickory Hill Consulting 4 Intended status: Standards Track D. Eastlake 5 Expires: 20 October 2022 Futurewei Technologies 6 C. Yadlapalli 7 ATT 8 S. Maduscke 9 Verizon 10 18 April 2022 12 BGP Flow Specification Version 2 13 draft-ietf-idr-flowspec-v2-00 15 Abstract 17 BGP flow specification version 1 (FSv1), defined in RFC 8955, RFC 18 8956, and RFC 9117 describes the distribution of traffic filter 19 policy (traffic filters and actions) distributed via BGP. Multiple 20 applications have used BGP FSv1 to distribute traffic filter policy. 21 These applications include the following: mitigation of denial of 22 service (DoS), enabling traffic filtering in BGP/MPLS VPNs, 23 centralized traffic control of router firewall functions, and SFC 24 traffic insertion. 26 During the deployment of BGP FSv1 a number of issues were detected 27 due to lack of consistent TLV encoding for rules for flow 28 specifications, lack of user ordering of filter rules and/or actions, 29 and lack of clear definition of interaction with BGP peers not 30 supporting FSv1. Version 2 of the BGP flow specification (FSv2) 31 protocol addresses these features. In order to provide a clear 32 demarcation between FSv1 and FSv2, a different NLRI encapsulates 33 FSv2. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on 20 October 2022. 51 Copyright Notice 53 Copyright (c) 2022 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 58 license-info) in effect on the date of publication of this document. 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. Code Components 61 extracted from this document must include Revised BSD License text as 62 described in Section 4.e of the Trust Legal Provisions and are 63 provided without warranty as described in the Revised BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Definitions and Acronyms . . . . . . . . . . . . . . . . 5 69 1.2. RFC 2119 language . . . . . . . . . . . . . . . . . . . . 6 70 2. Flow Specification . . . . . . . . . . . . . . . . . . . . . 6 71 2.1. Flow Specification v1 (FSv1) Overview . . . . . . . . . . 7 72 2.2. Flow Specification v2 (FSv2) Overview . . . . . . . . . . 9 73 3. FSv2 Filters and Actions . . . . . . . . . . . . . . . . . . 12 74 3.1. IP header SubTLV (type=1) . . . . . . . . . . . . . . . . 14 75 3.1.1. IP Destination Prefix (type = 1) . . . . . . . . . . 16 76 3.1.2. IP Source Prefix (type = 2) . . . . . . . . . . . . . 16 77 3.1.3. IP Protocol (type = 3) . . . . . . . . . . . . . . . 17 78 3.1.4. Port (type = 4) . . . . . . . . . . . . . . . . . . . 17 79 3.1.5. Destination Port (type = 5) . . . . . . . . . . . . . 18 80 3.1.6. Source Port (type = 6) . . . . . . . . . . . . . . . 18 81 3.1.7. ICMP Type (type = 7) . . . . . . . . . . . . . . . . 18 82 3.1.8. ICMP Code (type = 8) . . . . . . . . . . . . . . . . 19 83 3.1.9. TCP Flags (type = 9) . . . . . . . . . . . . . . . . 19 84 3.1.10. Packet length (type = 10 (0x0A)) . . . . . . . . . . 19 85 3.1.11. DSCP (Differentiaed Services Code Point)(type = 11 86 (0x0B)) . . . . . . . . . . . . . . . . . . . . . . . 20 87 3.1.12. Fragment (type = 12 (0x0C)) . . . . . . . . . . . . . 20 88 3.1.13. Flow Label(type = 13 (0xOD)) . . . . . . . . . . . . 21 89 3.1.14. TTL (type=14 (0x0E)) . . . . . . . . . . . . . . . . 21 90 3.1.15. Parts of SID (type = 15 (0xF)) . . . . . . . . . . . 21 91 3.1.16. MPLS Label Match1 (type=16, 0x10) . . . . . . . . . . 24 92 3.1.17. MPLS Label Match 2: Experimental bits match on top 93 label (Type=17 (0x11)) . . . . . . . . . . . . . . . 25 94 3.2. Encoding of FSV2 Actions (type=2) . . . . . . . . . . . . 26 95 3.2.1. Action Chain operation (ACO) (1, 0x01) . . . . . . . 28 96 3.2.2. Traffic Actions per interface set (TAIS) (2, 0x02) . 29 97 3.2.3. Traffic rate limited by bytes (TRB) (6, 0x06) . . . . 30 98 3.2.4. Traffic Action (TA)(7, 0x07) . . . . . . . . . . . . 30 99 3.2.5. Redirect to IPv4 (RDIPv4)(8,0x08) . . . . . . . . . . 31 100 3.2.6. Traffic marking (TM) (9, 0x09) . . . . . . . . . . . 32 101 3.2.7. Traffic rate limited by packets (TRP) (12, 0xC) . . . 33 102 3.2.8. Traffic redirect to IPv6 (RDIPv6) (13, 0xD) . . . . . 33 103 3.2.9. Traffic insertion in SFC (TISFC)(14, 0xE) . . . . . . 34 104 3.2.10. Flow Specification Redirect to Indirection-ID (RDIID) 105 (15, 0x0F) . . . . . . . . . . . . . . . . . . . . . 35 106 3.2.11. MPLS Label Action (MPLSLA)(16, 0x10) . . . . . . . . 36 107 3.2.12. VLAN action (VLAN) (22, 0x16) . . . . . . . . . . . . 37 108 3.2.13. TPID action (TPID) (23, 0x17) . . . . . . . . . . . . 39 109 3.3. Extended Community vs. Action SubTLV formats . . . . . . 39 110 3.4. L2 Traffic Rules . . . . . . . . . . . . . . . . . . . . 42 111 3.5. SFC Traffic Rules . . . . . . . . . . . . . . . . . . . . 43 112 3.6. BGP/MPLS VPN IP Traffic Rules . . . . . . . . . . . . . . 45 113 3.7. BGP/MPLS VPN L2 Traffic Rules . . . . . . . . . . . . . . 45 114 3.8. Encoding of Actions passed in Wide Communities . . . . . 46 115 4. Validation of FSv2 NLRI . . . . . . . . . . . . . . . . . . . 47 116 4.1. Validation of FS NLRI (FSv1 or FSv2) . . . . . . . . . . 47 117 4.2. Validation of Flow Specification Actions . . . . . . . . 49 118 4.3. Error handling and Validation . . . . . . . . . . . . . . 50 119 5. Ordering for Flow Specification v2 (FSv2) . . . . . . . . . . 50 120 5.1. Ordering of FSv2 NLRI Filters . . . . . . . . . . . . . . 50 121 5.2. Ordering of the Actions . . . . . . . . . . . . . . . . . 52 122 5.2.1. Action Chain Operation (ACO) . . . . . . . . . . . . 52 123 5.2.2. Summary of FSv2 ordering . . . . . . . . . . . . . . 55 124 6. Ordering of FS filters for BGP Peers support FSv1 and FSv2 . 56 125 7. Scalability and Aspirations for FSv2 . . . . . . . . . . . . 58 126 8. Optional Security Additions . . . . . . . . . . . . . . . . . 59 127 8.1. BGP FSv2 and BGPSEC . . . . . . . . . . . . . . . . . . . 59 128 8.2. BGP FSv2 with ROA . . . . . . . . . . . . . . . . . . . . 60 129 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 130 9.1. Flow Specification V2 SAFIs . . . . . . . . . . . . . . . 60 131 9.2. BGP Capability Code . . . . . . . . . . . . . . . . . . . 61 132 9.3. Filter IP Component types . . . . . . . . . . . . . . . . 61 133 9.4. FSV2 NLRI TLV Types . . . . . . . . . . . . . . . . . . . 62 134 9.5. Wide Community Assignments . . . . . . . . . . . . . . . 63 135 10. Security Considerations . . . . . . . . . . . . . . . . . . . 64 136 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 137 11.1. Normative References . . . . . . . . . . . . . . . . . . 64 138 11.2. Informative References . . . . . . . . . . . . . . . . . 67 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68 141 1. Introduction 143 Modern IP routers have the capability to forward traffic and to 144 classify, shape, rate limit, filter, or redirect packets based on 145 administratively defined policies. These traffic policy mechanisms 146 allow the operator to define match rules that operate on multiple 147 fields within header of an IP data packet. The traffic policy allows 148 actions to be taken upon a match to be associated with each match 149 rule. These rules can be more widely defined as "event-condition- 150 action" (ECA) rules where the event is always the reception of a 151 packet. 153 BGP ([RFC4271]) flow specification as defined by [RFC8955], 154 [RFC8956], [RFC9117] specifies the distribution of traffic filter 155 policy (traffic filters and actions) via BGP to a mesh of BGP peers 156 (IBGP and EBGP peers). The traffic filter policy is applied when 157 packets are received on a router with the flow specification function 158 turned on. The flow specification protocol defined in [RFC8955], 159 [RFC8956], and [RFC9117] will be called BGP flow specification 160 version 1 (BGP FSv1) in this draft. 162 Some modern IP routers also include the abilities of firewalls which 163 can match on a sequence of packet events based on administrative 164 policy. These firewall capabilities allow for user ordering of match 165 rules and user ordering of actions per match. 167 Multiple deployed applications currently use BGP FSv1 to distribute 168 traffic filter policy. These applications include: 1) mitigation of 169 Denial of Service (DoS), 2) traffic filtering in BGP/MPLS VPNS, and 170 3) centralized traffic control for networks utilizing SDN control of 171 router firewall functions, 4) classifiers for insertion in an SFC, 172 and 5) filters for SRv6 (segment routing v6). 174 During the deployment of BGP flow specification v1, the following 175 issues were detected: 177 * lack of consistent TLV encoding prevented extension of encodings, 179 * inability to allow user defined order for filtering rules, 181 * inability to order actions to provide deterministic interactions 182 or to allow users to define order for actions, and 184 * no clearly defined mechanisms for BGP peers which do not support 185 flow specification v1. 187 Networks currently cope with some of these issues by limiting the 188 type of traffic filter policy sent in BGP. Current Networks do not 189 have a good workaround/solution for applications that receive but do 190 not understand FSv1 policies. 192 This document defines version 2 of the BGP flow specification 193 protocol to address these shortcomings in BGP FSv1. Version 2 of BGP 194 flow specification will be denoted as BGP FSv2. 196 BGP FSv1 as defined in [RFC8955], [RFC8956], and [RFC9117] specified 197 2 SAFIs (133, 134) to be used with IPv4 AFI (AFI = 1) and IPv6 AFI 198 (AFI=2). 200 This document specifies 2 new SAFIs (TBD1, TBD2) for FSv2 to be used 201 with 5 AFIs (1, 2, 6, 25, and 31) to allow user-ordered lists of 202 traffic match filters for user-ordered traffic match actions encoded 203 in Communities (Wide or Extended). 205 FSv1 and FSv2 use different AFI/SAFIs to send flow specification 206 filters. Since BGP route selection is performed per AFI/SAFI, this 207 approach can be termed "ships in the night" based on AFI/SAFI. 209 FSv1 is a critical component of deployed applications. Therefore, 210 this specification defines how FSv2 will interact with BGP peers that 211 support either FSv2, FSv1, FSv2 and FSv1,or neither of them. It is 212 expected that a transition to FSv2 will occur over time as new 213 applications require FSv2 extensibility and user-defined ordering for 214 rules and actions or network operators tire of the restrictions of 215 FSv1 such as error handling issues and restricted topologies. 217 Section 2 contains the definition of Flow specification, a short 218 review of FSv1 and an overview of FSv2. Section 3 contains the 219 encoding rules for FSv2 and user-based encoding sent via BGP. 220 Section 4 describes how to validate FSv2 NLRI. Section 5 discusses 221 how to order FSV2 rules. Section 6 covers combining FSv2 user- 222 ordered match rules and FSv1 rules. Section 6 also discusses how to 223 combine user-ordered actions, FSv1 actions, and default actions. 224 Sections 7-10 address an alternate security mechanism, considerations 225 for IANA, security in deployments, and scalability aspirations. 227 1.1. Definitions and Acronyms 229 AFI - Address Family Identifier 231 AS - Autonomous System 233 BGPSEC - secure BGP [RFC8205] updated by [RFC8206] 234 BGP Session ephemeral state - state which does not survive the 235 loss of BGP peer session. 237 Configuration state - state which persist across a reboot of 238 software module within a routing system or a reboot of a hardware 239 routing device. 241 DDOs - Distributed Denial of Service. 243 Ephemeral state - state which does not survive the reboot of a 244 software module, or a hardware reboot. Ephemeral state can be 245 ephemeral configuration state or operational state. 247 FSv1 - Flow Specification version 1 [RFC8955] [RFC8956] 249 FSv2 - Flow Specification version 2 (this document) 251 NETCONF - The Network Configuration Protocol [RFC6241]. 253 RESTCONF - The RESTCONF configuration Protocol [RFC8040] 255 RIB - Routing Information Base. 257 ROA - Route Origin Authentication [RFC6482] 259 RR - Route Reflector. 261 SAFI - Subsequent Address Family Identifier 263 1.2. RFC 2119 language 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 267 document are to be interpreted as described in BCP 14 [RFC2119] 268 [RFC8174] when, and only when, they appear in all capitals as shown 269 here. 271 2. Flow Specification 273 A BGP Flow Specification is an n-tuple containing one or more match 274 criteria that can be applied to IP traffic, traffic encapsulated in 275 IP traffic or traffic associated with IP traffic. The following are 276 examples of such traffic: IP packet or an IP packet inside a L2 277 packet (Ethernet), an MPLS packet, and SFC flow. 279 A given Flow Specification NLRI may be associated with a set of path 280 attributes depending on the particular application, and attributes 281 within that set may or may not include reachability information 282 (e.g., NEXT_HOP). Extended Community or Wide Community attributes 283 (well-known or AS-specific) MAY be used to encode a set of pre- 284 determined actions. 286 A particular application is identified by a specific AFI/SAFI 287 (Address Family Identifier/Subsequent Address Family Identifier) and 288 corresponds to a distinct set of RIBs. Those RIBs should be treated 289 independently of each other in order to assure noninterference 290 between distinct applications. 292 BGP processing treats the NLRI as a key to entries in AFI/SAFI BGP 293 databases. Entries that are placed in the Loc-RIB are then 294 associated with a given set of semantics which are application 295 dependent. Standard BGP mechanisms such as update filtering by NLRI 296 or by attributes such as AS_PATH or large communities apply to the 297 BGP Flow Specification defined NLRI-types. 299 Network operators can control the propagation of BGP routes by 300 enabling or disabling the exchange of routes for a particular AFI/ 301 SAFI pair on a particular peering session. As such, the Flow 302 Specification may be distributed to only a portion of the BGP 303 infrastructure. 305 2.1. Flow Specification v1 (FSv1) Overview 307 The FSv1 NLRI defined in [RFC8955] and [RFC8956] include 13 match 308 conditions encoded for the following AFI/SAFIs: 310 * IPv4 traffic: AFI:1, SAFI:133 312 * IPv6 Traffic: AFI:2, SAFI:133 314 * BGP/MPLS IPv4 VPN: AFI:1, SAFI: 134 316 * BGP/MPLS IPv6 VPN: AFI:2, SAFI: 134 318 If one considers the reception of the packet as an event, then BGP 319 FSv1 describes a set of Event-MatchCondition-Action (ECA) policies 320 where: 322 * event is the reception of a packet, 324 * condition stands for "match conditions" defined in the BGP NLRI as 325 an n-tuple of component filters, and 327 * the action is either: the default condition (accept traffic), or a 328 set of actions (1 or more) defined in Extended BGP Community 329 values [RFC4360]. 331 The flow specification conditions and actions combine to make up FSv1 332 specification rules. Each FSv1 NLRI must have a type 1 component 333 (destination prefix). Extended Communities with FSv1 actions can be 334 attached to a single NLRI or multiple NLRIs in a BGP message 336 Within an AFI/SAFI pair, FSv1 rules are ordered based on the 337 components in the packet (types 1-13) ordered from left-most to 338 right-most and within the component types by value of the component. 339 Rules are inserted in the rule list by component-based order where an 340 FSv1 rule with existing component type has higher precedence than one 341 missing a specific component type, 343 Since FSv1 specifications ([RFC8955], [RFC8956], and [RFC9117]) 344 specify that the FSv1 NLRI MUST have a destination prefix (as 345 component type 1) embedded in the flow specification, the FSv1 rules 346 with destination components are ordered by IP Prefix comparison rules 347 for IPv4 ([RFC8955]) and IPv6 ([RFC8956]). [RFC8955] specifies that 348 more specific prefixes (aka longest match) have higher precedence 349 than that of less specific prefixes and that for prefixes of the same 350 length the lower IP number is selected (lowest IP value). [RFC8955] 351 specifies that if the offsets within component 1 are the same, then 352 the longest match and lowest IP comparison rules from [RFC8955] 353 apply. If the offsets are different, then the lower offset has 354 precedence. 356 These rules provide a set of FSv1 rules ordered by IP Destination 357 Prefix by longest match and lowest IP address. [RFC8955] also states 358 that the requirement for a destination prefix component "MAY be 359 relaxed by explicit configuration" Since the rule insertions are 360 based on comparing component types between two rules in order, this 361 means the rules without destination prefixes are inserted after all 362 rules which contain destination prefix component. 364 The actions specified in FSv1 are: 366 * accept packet (default), 368 * traffic flow limitation by bytes (0x6), 370 * traffic-action (0x7), 372 * redirect traffic (0x8), 374 * mark traffic (0x9), and 376 * traffic flow limitation by packets (12, 0xC) 377 Figure 1 shows a diagram of the FSv1 logical data structures with 5 378 rules. If FSv1 rules have destination prefix components (type=1) and 379 FSv1 rule 5 does not have a destination prefix, then FSv1 rule 5 will 380 be inserted in the policy after rules 1-4. 382 +--------------------------------------+ 383 | Flow Specification (FS) | 384 | Policy | 385 +--------------------------------------+ 386 ^ ^ ^ 387 | | | 388 | | | 389 +--------^----+ +-------^-------+ +-------------+ 390 | FS Rule 1 | | FS Rule 2 | ... | FS rule 5 | 391 +-------------+ +---------------+ +-------------+ 392 : : 393 : : 394 ...: :........ 395 : : 396 +---------V---------+ +----V-------------+ 397 | Rule Condition | | Rule Action | 398 | in BGP NLRIs | | in BGP extended | 399 | AFIs: 1 and 2 | | Communities | 400 | SAFI 133, 134 | | | 401 +-------------------+ +------------------+ 402 : : : : : : 403 .....: . :..... .....: . :..... 404 : : : : : : 405 +----V---+ +---V----+ +--V---+ +-V------+ +--V-----++--V---+ 406 | Match | | match | |match | | Action | | action ||action| 407 |Operator| |Variable| |Value | |Operator| |variable|| Value| 408 |*1 | | | | | |(subtype| | || | 409 +--------+ +--------+ +------+ +--------+ +--------++------+ 411 *1 match operator may be complex. 413 Figure 2-1: BGP Flow Specification v1 Policy 415 2.2. Flow Specification v2 (FSv2) Overview 417 Flow Specification v2 allows the user to order the flow specification 418 rules and the actions associated with a rule. Each FSv2 rule may 419 have one or more match conditions and one or more associated actions. 421 This FSv2 specification supports the components and actions for the 422 following: 424 * IPv4 (AFI=1, SAFI=TBD1), 426 * IPv6 (AFI=2, SAFI=TBD2), 428 * L2 (AFI=6, SAFI=TDB1), 430 * BGP/MPLS IPv4 VPN: (AFI=1, SAFI=TBD2), 432 * BGP/MPLS IPv6 VPN: (AFI=2, SAFI=TBD2), 434 * BGP/MPLS L2VPN (AFI=25, SAFI=TDB2), 436 * SFC: (AFI=31, SAFI=TBD1), and 438 * SFC VPN (AFI=31, SAFI=TBD2). 440 The FSv2 specification for tunnel traffic is outside the scope of 441 this specification. The FSv1 specification for tunneled traffic is 442 in [I-D.ietf-idr-flowspec-nvo3]. 444 FSv2 operates in the ships-in-the night model with FSv1 so network 445 operators can manipulate which the distribution of FSv2 and FSv1 446 using configuration parameters. Since the lack of deterministic 447 ordering was an FSv1 problem, this specification provides rules and 448 protocol features to keep filters in a deterministic order between 449 FSv1 and FSv2. 451 The basic principles regarding ordering of flow specification filter 452 rules are: 454 1) Rule-0 (zero) is defined to be 0/0 with the "permit-all" 455 action. 457 2) FSv2 rules are ordered based on user-specified order. 459 - The user-specified order is carried in the FSv2 NLRI and a 460 numerical lower value takes precedence over a numerically 461 higher value. For rules received with the same order value, 462 the FSv1 rules apply (order by component type and then by value 463 of the components). 465 3) FSv2 rules are added starting with Rule 1 and FSv1 rules are 466 added after FSv2 rules 468 - For example, BGP Peer A has FSv2 data base with 10 FSv2 rules 469 (1-10). FSv1 user number is configured to start at 301 so 10 470 FSv1 rules are added at 301-310. 472 4) An FSv2 peer may receive BGP NLRI routes from a FSv1 peer or a 473 BGP peer that does not support FSv1 or FSv2. The capabilities 474 sent by a BGP peer indicate whether the AFI/SAFI can be received 475 (FSv1 NLRI or FSv2 NLRI). 477 5) Associate a chain of actions to rules based on user-defined 478 action number (1-n). (optional) 480 - If no actions are associated with a filter rule, the default is 481 to drop traffic the filter rules match 483 - An action chain of 1-n actions can be associated with a set of 484 filter rules can via Extended Communities or Wide Communities. 485 Only Wide Communities can associate a user-defined order for 486 the actions. Extended Community actions occur after actions 487 with a user specified order (see section 5.2 for details). 489 Figure 2-2 provides a logical diagram of the FSv2 structure 490 +--------------------------------+ 491 | Rule Group | 492 +--------------------------------+ 493 ^ ^ ^ 494 | |--------- | 495 | | ------ 496 | | | 497 +--------^-------+ +-------^-----+ +---^-----+ 498 | Rule1 | | Rule2 | ... | Rule-n | 499 +----------------+ +-------------+ +---------+ 500 : : : : 501 :.................: : : : 502 : |.........: : : 503 +--V--+ +--V--+ : : 504 | name| |order| .........: :..... 505 +-----+ +-----+ : : 506 : : 507 +----------------V----+ +-----V----------------+ 508 |Rule Match condition | | Rule Action | 509 +---------------------+ +----------------------+ 510 : : : : : : : : | 511 +--V--+ : : : +--V---+ : : : V 512 | Rule| : : : |action| : : : +-----------+ 513 | name| : : : |order | : : : |action name| 514 +-----+ : : : +------+ : : : +-----------+ 515 : : : : : :............. 516 : : : : : : 517 .....: . :..... ..: :...... : 518 : : : : : : 519 +----V---+ +---V----+ +--V---+ +-V------+ +--V-----+ +--V---+ 520 | Match | | match | |match | | Action | | action | |action| 521 |Operator| |variable| |Value | |Operator| |Variable| | Value| 522 +--------+ +--------+ +------+ +--------+ +--------+ +------+ 524 Figure 2-2: BGP FSv2 Data storage 526 3. FSv2 Filters and Actions 528 The BGP FSv2 uses an NRLI with the format for AFIs for IPv4 (AFI = 529 1), IPv6 (AFI = 2), L2 (AFI = 6), L2VPN (AFI=25), and SFC (AFI=31) 530 with two following SAFIs to support transmission of the flow 531 specification which supports user ordering of traffic filters and 532 actions for IP traffic and IP VPN traffic. 534 This NLRI information is encoded using MP_REACH_NLRI and 535 MP_UNREACH_NLRI attributes defined in [RFC4760]. When advertising 536 FSv2 NLRI, the length of the Next-Hop Network Address MUST be set to 537 0. Upon reception, the Network Address in the Next-Hop field MUST be 538 ignored. 540 Implementations wishing to exchange flow specification rules MUST use 541 BGP's Capability Advertisement facility to exchange the Multiprotocol 542 Extension Capability Code (Code 1) as defined in [RFC4760], and 543 indicate a capability for FSv1, FSv2 (Code TBD3), or both. 545 The AFI/SAFI NLRI for BGP Flow Specification version 2 (FSv2) has the 546 format: 548 +-------------------------------+ 549 |length (2 octets) | 550 +-------------------------------+ 551 | Sub-TLVs (variable) | 552 | +===========================+ | 553 | | order (4 octets) | | 554 | +---------------------------+ | 555 | | identifier (4 octets) | | 556 | +---------------------------+ | 557 | | type (2 octets) | | 558 | +---------------------------+ | 559 | | length-Subtlv (2 octets) | | 560 | +---------------------------+ | 561 | | value (variable) | | 562 | +===========================+ | 563 +-------------------------------+ 565 Figure 3-1: FSv2 format 567 where: 569 * length: length of field including all SubTLVs in octets. 571 - The combined lengths of any FSv2 NLRI in the MP_REACH_NLRI or 572 MP_UNREACH_NLRI. The BGP NLRI length must be less than the 573 packet size minus the other fields (BGP header, BGP Path 574 Attributes, and NLRI). 576 * order: flow-specification global rule order number (4 octets). 578 * identifier: identifier for the rule (used for NM/Logging) (4 579 octets) 581 * type: contains a type for FSv2 TLV format of the NRLI (2 octets) 582 which can be: 584 - 0 - reserved, 586 - 1 - IP Traffic Rules 588 - 2- L2 traffic rules 590 - 3- SFC Traffic rules 592 - 4- SFC VPN Traffic rules 594 - 5 - BGP/MPLS VPN IP Traffic Rules 596 - 6 - BGP/MPLS VPN L2 Traffic Rules 598 * length-Subtlv: is the length of the value part of the Sub-TLV, 600 * value: value depends on the subTLV (see sections below). 602 3.1. IP header SubTLV (type=1) 604 The format of the IP header TLV value field is shown in figure 4. 605 The AFI/SAFI field includes the AFI (2 octets), SAFI (1 octet). The 606 AFI will be 1 (IPv4) or 2 (IPv6) and the SAFI will be TBD1 or, for 607 the VPN case, TBD2. The IP header for the VPN case is specified in 608 section 3.5. 610 +-------------------------------+ 611 | +--------------------------+ | 612 | | AFI/SAFI field (3) | | 613 | +--------------------------+ | 614 | | (subTLVs)+ | | 615 | +==========================+ | 616 +-------------------------------+ 618 Figure 3-2 - IP Header TLV 620 Where: AFI is 1 (IPv4) or 2 (IPv6) and SAFI is TBD1. 622 Each SubTLV has the format: 624 +-------------------------------+ 625 | SubTLV type (1 octet) | 626 +-------------------------------+ 627 | length (1 octet) | 628 + ------------------------------+ 629 | value (variable) | 630 +-------------------------------+ 631 Figure 3-3 – IP header SubTLV format 633 Where: 635 SubTLV type: component values are defined in the "Flow 636 Specification Component types" registry for IPv4 and IPv6 by 637 [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6] 639 length: length of SubTLV (varies depending on SubTLV type). 641 value: dependent on the subTLV 643 - For descriptions of value portions for components 1-13 see 644 [RFC8955] and [RFC8956]. For component 14 see 645 [I-D.ietf-idr-flowspec-srv6]. 647 Many of the components use the operators [numeric_op] and 648 [bitmask_op] defined in [RFC8955] 650 The list of valid SubTLV types appears in Table 2. 652 Table 2 IP SubTLV Types for IP Filters 653 SubTLV-type Definition 654 =========== ============ 655 1 – IP Destination prefix 656 2 – IP Source prefix 657 3 – IPv4 Protocol / IPv6 Upper Layer Protocol 658 4 – Port 659 5 – Destination Port 660 6 – Source Port 661 7 – ICMPv4 type / ICMPv6 type 662 8 – ICMPv4 code / ICPv6 code 663 9 – TCP Flags 664 10 – Packet length 665 11 – DSCP (Differentiated Services Code Point) 666 12 – Fragment 667 13 – Flow Label 668 14 - TTL 669 15 – Parts of SID 670 16 - MPLS Match 1: Label in Label stack 671 17 - MPLS Match 2: EXP bits in top Label 672 Ordering within the TLV in FSv2: The transmission of SubTLVs within a 673 flow specification rule MUST be sent ascending order by SubTLV type. 674 If the SubTLV types are the same, then the value fields are compared 675 using mechanisms defined in [RFC8955] and [RFC8956] and MUST be in 676 ascending order. NLRIs having TLVs which do not follow the above 677 ordering rules MUST be considered as malformed by a BGP FSv2 678 propagator. This rule prevents any ambiguities that arise from the 679 multiple copies of the same NLRI from multiple BGP FSv2 propagators. 680 A BGP implementation SHOULD treat such malformed NLRIs as "Treat-as- 681 withdraw" [RFC7606]. 683 See [RFC8955], [RFC8956], and [I-D.ietf-idr-flowspec-srv6]. for 684 specific details. 686 3.1.1. IP Destination Prefix (type = 1) 688 IPv4 Name: IP Destination Prefix (reference: [RFC8955]) 690 IPv6 Name: IPv6 Destination Prefix (reference: [RFC8956]) 692 IPv4 length: Prefix length in bits 694 IPv4 value: IPv4 Prefix (variable length) 696 IPv6 length: length of value 698 IPv6 value: [offset (1 octet)] [pattern (variable)] 699 [padding(variable)] 701 If IPv6 length = 0 and offset = 0, then component matches every 702 address. Otherwise, length must be offset "less than" length "less 703 than" 129 or component is malformed. 705 3.1.2. IP Source Prefix (type = 2) 707 IPv4 Name: IP Source Prefix (reference: [RFC8955]) 709 IPv6 Name: IPv6 Source Prefix (reference: [RFC8956]) 711 IPv4 length: Prefix length in bits 713 IPv4 value: Source IPv4 Prefix (variable length) 715 IPv6 length: length of value 716 IPv6 value: [offset (1 octet)] [pattern 717 (variable)][padding(variable)] 719 If IPv6 length = 0 and offset = 0, then component matches every 720 address. Otherwise, length must be offset < length < 129 or 721 component is malformed. 723 3.1.3. IP Protocol (type = 3) 725 IPv4 Name: IP Protocol IP Source Prefix (reference: [RFC8955]) 727 IPv6 Name: IPv6 Upper-Layer Protocol: (reference: [RFC8956]) 729 IPv4 length: variable 731 IPv4 value: [numeric_op, value]+ 733 IPv6 length: variable 735 IPv6 value: [numeric_op, value}+ 737 where the value following each numeric_op is a single octet. 739 3.1.4. Port (type = 4) 741 IPv4/IPv6 Name: Port (reference: [RFC8955]), [RFC8956]) 743 Filter defines: a set of port values to match either destination port 744 or source port. 746 IPv4 length: variable 748 IPv4 value: [numeric_op, value]+ 750 IPv6 length: variable 752 IPv6 value: [numeric_op, value]+ 754 where the value following each numeric_op is a single octet. 756 Note-1: (from FSV1) In the presence of the port component 757 (destination or source port), only a TCP (port 6) or UDP (port 17) 758 packet can match the entire flow specification. If the packet is 759 fragmented and this is not the first fragment, then the system may 760 not be able to find the header. At this point, the FSv2 filter may 761 fail to detect the correct flow. Similarly, if other IP options or 762 the encapsulating security payload (ESP) is present, then the node 763 may not be able to describe the transport header and the FSv2 filter 764 may fail to detect the flow. 766 The restriction in note-1 comes from the inheritance of the FSv1 767 filter component for port. If better resolution is desired, a new 768 FSv2 filter should be defined. 770 Note-2: FSv2 component only matches the first upper layer protocol 771 value. 773 3.1.5. Destination Port (type = 5) 775 IPv4/IPv6 Name: Destination Port (reference: [RFC8955]), [RFC8956]) 777 Filter defines: a list of match filters for destination port for TCP 778 or UDP within a received packet 780 Length: variable 782 Component Value format: [numeric_op, value]+ 784 3.1.6. Source Port (type = 6) 786 IPv4/IPv6 Name: Source Port (reference: [RFC8955]), [RFC8956]) 788 Filter defines: a list of match filters for source port for TCP or 789 UDP within a received packet 791 IPv4/IPv6 length: variable 793 IPv4/Ipv6 value: [numeric_op, value]+ 795 3.1.7. ICMP Type (type = 7) 797 IPv4: ICMP Type (reference: [RFC8955]) 799 Filter defines: Defines: a list of match criteria for ICMPv4 type 801 IPv6: ICMPv6 Type (reference: [RFC8956]) 803 Filter defines: a list of match criteria for ICMPv6 type. 805 IPv4/IPv6 length: variable 807 IPv4/IPv6 value: [numeric_op, value]+ 809 3.1.8. ICMP Code (type = 8) 811 IPv4: ICMP Type (reference: [RFC8955]) 813 Filter defines: a list of match criteria for ICMPv4 code. 815 IPv6: ICMPv6 Type (reference: [RFC8956]) 817 Filter defines: a list of match criteria for ICMPv6 code. 819 IPv4/IPv6 length: variable 821 IPv4/IPv6 value: [numeric_op, value]+ 823 3.1.9. TCP Flags (type = 9) 825 IPv4/IPv6: TCP Flags Code (reference: [RFC8955]) 827 Filter defines: a list of match criteria for TCP Control bits 829 IPv4/IPv6 length: variable 831 IPv4/IPv6 value: [bitmask_op, value]+ 833 Note: a 2 octets bitmask match is always used for TCP-Flags 835 3.1.10. Packet length (type = 10 (0x0A)) 837 IPv4/IPv6: Packet Length (reference: [RFC8955], [RFC8956]) 839 Filter defines: a list of match criteria for length of packet 840 (excluding L2 header but including IP header). 842 IPv4/IPv6 length: variable 844 IPv4/IPv6 value: [numeric_op, value]+ 846 Note:[RFC8955] uses either 1 or 2 octet values. 848 3.1.11. DSCP (Differentiaed Services Code Point)(type = 11 (0x0B)) 850 IPv4/IPv6: DSCP Code (reference: [RFC8955], [RFC8956]) 852 Filter defines: a list of match criteria for DSCP code values to 853 match the 6-bit DSCP field. 855 IPv4/IPv6 length: variable 857 IPv4/IPv6 value: [numeric_op, value]+ 859 Note: This component uses the Numeric Operator (numeric_op) described 860 in [RFC8955] in section 4.2.1.1. Type 11 component values MUST be 861 encoded as single octet (numeric_op len=00). 863 The six least significant bits contain the DSCP value. All other 864 bits SHOULD be treated as 0. 866 3.1.12. Fragment (type = 12 (0x0C)) 868 IPv4/IPv6: Fragment (reference: [RFC8955], [RFC8956]) 870 Filter defines: a list of match criteria for specific IP fragments. 872 Length: variable 874 Component Value format: [bitmask_op, value]+ 876 Bitmask values are: 878 0 1 2 3 4 5 6 7 879 +---+---+---+---+---+---+---+---+ 880 | 0 | 0 | 0 | 0 |LF |FF |IsF| DF| 881 +---+---+---+---+---+---+---+---+ 882 Figure 3-4 884 Where: 886 DF (don't fragment): match If IP header flags bit 1 (DF) is 1. 888 IsF(is a fragment other than first: match if IP header fragment 889 offset is not 0. 891 FF (First Fragment): Match if [RFC0791] IP Header Fragment offset 892 is zero and Flags Bit-2 (MF) is 1. 894 LF (last Fragment): Match if [RFC7091] IP header Fragment is not 0 895 And Flags bit-2 (MF) is 0 897 0: MUST be sent in NLRI encoding as 0, and MUST be ignored during 898 reception. 900 3.1.13. Flow Label(type = 13 (0xOD)) 902 IPv4/IPv6: Fragment (reference: [RFC8956]) 904 Filter defines: a list of match criteria for 20-bit Flow Label in the 905 IPv6 header field. 907 Length: variable 909 Component Value format: [numeric_op, value]+ 911 3.1.14. TTL (type=14 (0x0E)) 913 TTL: Defines matches for 8-bit TTL field in IP header 915 Encoding: <[numeric_op, value]+> 917 where: value is a 1 octet value for TTL. 919 ordering: by full value of number_op concatenated with value 921 conflict: none 923 reference: draft-bergeon-flowspec-ttl-match-00.txt 925 3.1.15. Parts of SID (type = 15 (0xF)) 927 IPv6: Service Identifier Matches (reference: 928 [I-D.ietf-idr-flowspec-srv6] 930 Filter defines: a list of match bit match criteria for some 931 combinations of the LOC (location), FUNCT (function) and ARG 932 (arguments) fields in the SID or or whole SID. 934 Length: variable 936 Component Value format: [type, LOC-Len, FUNCT-Len, ARG-Len, [op, 937 value]+] 939 where: 941 * type (1 octet): This indicates the new component type (TBD1, which 942 is to be assigned by IANA). 944 * LOC-Len (1 octet): This indicates the length in bits of LOC in 945 SID. 947 * FUNCT-Len (1 octet): This indicates the length in bits of FUNCT in 948 SID. 950 * ARG-Len (1 octet): This indicates the length in bits of ARG in 951 SID. 953 * [op, value]+: This contains a list of {operator, value} pairs that 954 are used to match some parts of SID. 956 The total of three lengths (i.e., LOC length + FUNCT length + ARG 957 length) MUST NOT be greater than 128. If it is greater than 128, an 958 error occurs and it is treated as a withdrawal [RFC7606] and 959 [RFC4760]. 961 The operator (op) byte is encoded as: 963 0 1 2 3 4 5 6 7 964 +---+---+---+---+---+---+---+---+ 965 | e | a | field type|lt |gt |eq | 966 +---+---+---+---+---+---+---+---+ 967 Figure 3-5 969 where: 971 where the behavior of each operator bit has clear similarity with 972 that of [RFC8955]'s Numeric Operator field. 974 e (end-of-list bit): Set in the last {op, value} pair in the 975 sequence. 977 a - AND bit: If unset, the previous term is logically ORed with 978 the current one. If set, the operation is a logical AND. It 979 should be unset in the first operator byte of a sequence. The AND 980 operator has higher priority than OR for the purposes of 981 evaluating logical expressions. 983 field type: 985 - 000: SID's LOC 987 - 001: SID's FUNCT 988 - 010: SID's ARG 990 - 011: SID's LOC:FUNCT (the concatenation of the LOC and FUNCTION 991 fields) 993 - 100: SID's FUNCT:ARG (the concatenation of the FUNCTION and ARG 994 fields) 996 - 101: SID's LOC:FUNCT:ARG (the concatenation of the FUNCTION and 997 ARG fields) 999 Note: For an unknown field type, Error Handling is to "treat as 1000 withdrawal" [RFC7606] and [RFC4760]. 1002 lt: less than comparison between data' and value'. 1004 gt: greater than comparison between data' and value'. 1006 eq: equality between data' and value'. 1008 The data' and value' used in lt, gt and eq are indicated by the field 1009 type in an operator and the value field following the operator. 1011 The length of the value field depends on the field type and is the 1012 length of the SID parts being matched (see Table 3, Figure 3-6) in 1013 bytes, rounded up if that length is not a multiple of 8. 1015 Table 3 - SID Parts fields 1017 +-----------------------+------------------------------+ 1018 | Field Type | Value | 1019 +=======================+==============================+ 1020 | SID's LOC | value of LOC bits | 1021 +-----------------------+------------------------------+ 1022 | SID's FUNCT | value of FUNCT bits | 1023 +-----------------------+------------------------------+ 1024 | SID's ARG | value of ARG bits | 1025 +-----------------------+------------------------------+ 1026 | SID's LOC:FUNCT | value of LOC:FUNCT bits | 1027 +-----------------------+------------------------------+ 1028 | SID's FUNCT:ARG | value of FUNCT:ARG bits | 1029 +-----------------------+------------------------------+ 1030 | SID's LOC:FUNCT:ARG | value of LOC:FUNCT:ARG bits | 1031 +-----------------------+------------------------------+ 1032 ------------------ SID, 128 bits ---------------- 1033 / \ 1034 +-----------+-----------+-----------+----------------+ 1035 | LOC | FUNCT | ARG | ... | 1036 +-----------+-----------+-----------+----------------+ 1037 \ / \ / \ / \ / 1038 j bits k bits m bits 128-j-k-m bits 1039 \ / 1040 LOC:FUNCT, j+k bits 1041 \ / 1042 FUNCT:ARG, k+m bits 1043 \ / 1044 -- LOC:FUNCT:ARG, j+k+m bits – 1046 Figure 3-6 1048 3.1.16. MPLS Label Match1 (type=16, 0x10) 1050 Function: This match1 applies to MPLS Label field on the label 1051 stack. 1053 reference: [I-D.ietf-idr-flowspec-mpls-match] 1055 Encoding: . 1057 It contains a set of {operator, value} pairs that are used for the 1058 matching filter. 1060 The operator byte is encoded as: 1062 0 1 2 3 4 5 6 7 1063 +---+---+---+---+---+---+---+---+ 1064 | e | a | i | pos | Resv | 1065 +---+---+---+---+---+---+---+---+ 1066 Figure 3-7 1068 where: 1070 e - end of list bit: Set in the last {op, value} pair in the 1071 list. 1073 a - AND bit: If unset, the previous term is logically ORed with 1074 the current one. If set, the operation is a logical AND. It 1075 should be unset in the first operator byte of a sequence. The 1076 AND operator has higher priority than OR for the purposes of 1077 evaluating logical expressions. 1079 i - before bit: If unset, apply matching filter before MPLS label 1080 data plane action; if set, apply matching filter after MPLS 1081 label data plane action. 1083 pos - the label position indication bits: whose meaning for 1084 various values is shown below: 1086 00:any position on the label stack - the presented label value 1087 is used to match any label on the label stack. When 1088 applying it, at least one label on the stack MUST match the 1089 value 1091 01:top label indication- the presented label value MUST be 1092 used to match the top label on the label stack. 1094 10: bottom label indication- the presented label value MUST 1095 match the bottom label on the label stack. When it is 1096 clear, the present label value can match to any label on the 1097 label stack 1099 11: reserved value - - This value is reserved and MUST not be 1100 sent in the packet. 1102 The value field is encoded as: 1104 1 2 1105 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Label | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 Figure 3-8 1111 reference: 1113 3.1.17. MPLS Label Match 2: Experimental bits match on top label 1114 (Type=17 (0x11)) 1116 Function: MPLS Match2 applies to MPLS Label experiment bits (EXP) 1117 on the top label in the label stack. 1119 reference: [I-D.ietf-idr-flowspec-mpls-match] 1121 Encoding: 1123 - [op,value] - Defines a list of {operation, value} pairs used to 1124 match 3-bit exp field on the top label of packets [RFC3032]. 1126 - Values are encoded using a single byte, where the five most 1127 significant bits are zero and the three least significant bits 1128 contain the exp value. 1130 3.2. Encoding of FSV2 Actions (type=2) 1132 The FSv2 actions may be sent in an Extended Community or a Wide 1133 Community. 1135 The Extended Community encodes the Flow Specification actions in the 1136 Extended Community format [RFC4360]. 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Type high | Type low(*) | | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (6 octets) | 1143 | | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 Figure 3-9 1148 The Wide Community definition for FSv2 actions is as follows: 1150 0 1 2 3 1151 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 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Type=1 | Flags |C|T| Reserved | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Length |+ | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 Figure 3-10 1160 where FSv2-Action-TLV is defined as: 1162 FSv2-Action-TLV 1163 0 1 2 3 1164 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 1165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 | action order | Chain-ID | 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 | | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 Figure 3-11 1173 Where action-SubTLVs have the format: 1175 action-SubTLVs 1177 0 1 2 3 1178 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 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | SubTLV type (2 octet) | length type (2 octet) | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | value (variable) | 1183 +-------------------------------+ 1185 Figure 3-12 1187 where: 1189 action-order: is the user defined order of the action within the 1190 list 1192 chain ID: is a 2-byte identifier for an action chain 1194 length - is the length of the TLV 1196 value - contains a sequence of action SubTLVs. 1198 Each Action SubTLV has the format: 1200 +-------------------------------+ 1201 | SubTLV type (2 octet) | 1202 +-------------------------------+ 1203 | length (2 octet) | 1204 +-------------------------------+ 1205 | value (variable) | 1206 +-------------------------------+ 1208 Figure 3-14 1210 Where: 1212 * SubTLV type: values are action type values shown in Table 4 below. 1214 * length: is the length of the action SubTLV 1216 * Value is specific to the SubTLV 1217 Table 4 – FSv2 Action types 1219 Action Description 1220 ====== =========== 1221 00 reserved 1222 01 ACO: action chain operation 1223 02 TAIS: traffic actions per interface group 1224 06 TRB: traffic rate limited by bytes 1225 07 TA: traffic action (terminal/sample) 1226 08 RDIP: Redirect IPv4 1227 09 TM: mark DSCP value 1228 10 TBA (to be assigned) 1229 11 TBA (to be assigned) 1230 12 TRP: traffic rate limited by packets 1231 13 RDIPv6: redirect to IPv6 1232 14 TISFC: SFC Classifier Info (moved from OD to OE) 1233 15 RDIID: redirect to Indirection-id (move from 0x00) 1234 16 MPLSLA: MPLS label action 1235 17-21 TBA (to be assigned) 1236 22 VLAN: VLAN-Action (0x16)[draft-ietf-idr-flowspec-l2vpn-17] 1237 23 TPID: TPID-Action (0x17)[draft-ietf-idr-flowspec-l2vpn-17] 1238 24-254 TBA (to be assigned) 1239 255 reserved 1241 Figure 3-15 1243 Ordering of actions within a rule: 1245 The actions are first stored in user-defined order. If multiple 1246 actions exist for a single action order value, then the actions 1247 will be ordered by action type followed by value. 1249 Action specifications must include descriptions of order 1250 comparison for the values within the action. 1252 3.2.1. Action Chain operation (ACO) (1, 0x01) 1254 SubTLV: 0x01 1256 Length: variable 1258 Value: 1260 AC-failure-type - byte that determines the action on failure 1262 AC-failure-value - variable depending on AC-failure-type. 1264 Actions may succeed or fail and an Action chain must deal with it. 1265 The default value stored for an action chain that does not have this 1266 action chain is "stop on failure". 1268 where: 1270 AC-Failure types are: 1272 - 0x00 - default - stop on failure 1274 - 0x01 - continue on failure (best effort on actions) 1276 - 0x02 - conditional stop on failure - depending on AC-Failure- 1277 value 1279 - 0x03 - rollback - do all or nothing - depending in AC-Failure- 1280 value 1282 AC-Failure values: TBD 1284 Interactions with other actions: Interactions with all other Actions 1286 Ordering within Action type: By AC-Failure type 1288 3.2.2. Traffic Actions per interface set (TAIS) (2, 0x02) 1290 SubTLV: 0x02 1292 Length: 8 octets (6 in extended community) 1294 Value field: [4-octet-AS] [GroupID 2-octet] [action 2-octet] 1296 where: 1298 Group-ID: identifier for group in 2 octets (14 lower bits) 1300 - Note: Extended Community format will have 2 bits for action. 1302 Action: determines inbound or outbound action where: 1304 - Outbound(0x1): FSv2 rule MUST be applied in outbound Direction 1305 to interface set identified by Group-ID. 1307 - Inbound (0x2): FSv2 rule MUST be applied in inbound Direction 1308 to interface set identified by Group-ID. 1310 Value ordering: AS, then Group ID, then Action bytes. 1312 Conflict: with any bi-direction action such as 1314 1. traffic rate limited by bytes, or 1316 2. traffic rate limited by packets. 1318 Reference: [I-D.ietf-idr-flowspec-interfaceset] 1320 3.2.3. Traffic rate limited by bytes (TRB) (6, 0x06) 1322 SubTLV:0x06 1324 Length: 8 octets 1326 Value field:[4-octet-AS] [float (4 bytes)] 1328 where: 1330 [4-octet-AS]:4 byte AS number 1332 - If FSv1 passes the lower 2 bytes of 4 byte AS number, use 1333 [TBD6] as higher 2 bytes to identify. 1335 - Open issue : TBD6 can be either be chosen to match the common 1336 2-byte to 4-byte or a unique value. Feedback is needed from WG 1337 and authors. 1339 Float: maximum byte rate in IEEE 32-bit floating point 1340 [IEEE.754.19895 format] in bytes per second. 1342 - A value of 0 should result in all traffic for the particular 1343 flow to be discarded. 1345 - On encoding the traffic-rate-packets MUST NOT be negative. 1347 - On decoding, negative values MUST BE treated as zero (discard 1348 all traffic). 1350 Value ordering: AS then float value 1352 Action Conflict: traffic-rate-packets 1354 reference: [RFC8955] 1356 3.2.4. Traffic Action (TA)(7, 0x07) 1358 SubTLV: 0x07 1359 Length: 1 1361 Value field: [1-octet action] 1363 where the traffic action values are: 1365 1 = Terminal flow specification action 1367 2 = Sample - enables sampling and logging 1369 3 = Terminal action + sample 1371 Value ordering: By traffic action values 1373 Conflicts/Interactions: duplication of packets also occurs in: 1375 Redirect to IPv4 (action 0x08), 1377 Redirect to IPv6 (action 0x0D (13)), 1379 Redirect to SFC (action 0xOE (14)) 1381 Redirect to Indirection-ID (action 0xF (15) 1383 3.2.5. Redirect to IPv4 (RDIPv4)(8,0x08) 1385 SubTLV: 0x08 1387 Length: 12 octets 1389 Value field: 1391 [4-byte-AS] [IPv4 address (4 octets] [ID (4 octets)] [Flag (1 octet)] 1393 where: 1395 4-octet-AS - is a 4-byte AS in a Route Target 1397 IPv4 address - is an IP Address in RT 1399 ID - the 4-octet value set by user 1401 Flag is 1 octet value with the following definitions: 1403 - 0 - reserved 1405 - 1 - copy and redirect copy 1407 Value ordering: 4-octet AS, then IP address, then ID (lowest to 1408 highest) with: 1410 No AS specified uses AS value of zero. 1412 No IP specified uses IP value of zero. 1414 No ID specified uses ID value of zero. 1416 Conflicts/Interactions: Any redirection or traffic sampling found in: 1418 Traffic Action (action 0x07), 1420 Redirect to IPv6 (action 0x0D (13)), 1422 Redirect to SFC (action 0xOE (14)) 1424 Redirect to Indirection-ID (action 0xF (15) 1426 reference: [RFC8955], draft-ietf-idr-flowspec-ip-02.txt 1428 3.2.6. Traffic marking (TM) (9, 0x09) 1430 SubTLV: 0x09 1432 Length: 1 octet 1434 Value: DSCP field with the 2 left most bits zero 1436 The DSCP field format is: 1438 0 1 2 3 4 5 6 7 1439 +--+--+--+--+--+--+--+--+ 1440 |R |R | DSCP bits | 1441 +--+--+--+--+--+--+--+--+ 1443 Figure 3-16 1445 where: 1447 R - reserved bits (set to zero to send, ignored upon reception and 1448 set to zero. 1450 DSCP - 6 bits of DSCP values 1452 Ordering within Value: Based on DSCP value 1453 Conflicts: none 1455 reference: [RFC8955] 1457 3.2.7. Traffic rate limited by packets (TRP) (12, 0xC) 1459 SubTLV:12 (0xC) 1461 Length: 8 1463 Value field: [4-octet-AS] [float (4 octet)] 1465 Where: 1467 4-octet AS - is the AS setting this value 1469 Float - specifies maximum rate in IEEE 32-bit format 1470 [IEEE.754.185] in packets per second. 1472 - A traffic rate of zero should result in all packets being 1473 discard. 1475 - On encoding the traffic-rate-packets MUST NOT be negative. 1477 - On decoding, negative values MUST BE treated as zero (discard 1478 all traffic). 1480 Ordering within Value: Based on DSCP value 1482 Conflicts: Traffic rate limited by bytes (0x06) 1484 reference: [RFC8955] 1486 3.2.8. Traffic redirect to IPv6 (RDIPv6) (13, 0xD) 1488 SubTLV: 13 (0xD) 1490 Length: 24 octets 1492 Value field: [4-octet-as] [IPv6-address (16 octets)] [local 1493 administrator (2 octets] [Flag (1 octets)] 1495 where: 1497 4-octet-AS - is the AS requesting action in 4-byte AS format, 1499 IPv6-address - is the redirection IPv6 address 1500 Local administrator - 2 bytes assigned by network administrator. 1502 lag (1 octet) with the following definitions: 1504 - 0 - reserved 1506 - 1 - copy and redirect copy 1508 Ordering within Value: AS, then IPv6, the flag (low to high) 1510 Conflicts/Interactions: Any redirection or traffic sampling found in: 1512 Traffic Action (action 0x07) , 1514 Redirect to IPv4 (action 0x08 (8)), 1516 Redirect to SFC (action 0xOE (14)) 1518 Redirect to Indirection-ID (action 0xF (15) 1520 3.2.9. Traffic insertion in SFC (TISFC)(14, 0xE) 1522 SubTLV:14 (0xE) 1524 Note: replace IANA 0xD FSv1 with FSv2 OxE. 1526 Length: 6 octets 1528 Value field: [SPI (3 octets)][SI (1 octet)][SFT (2 octet)] 1530 where: 1532 SPI - is the service path identifier 1534 SI - is the service index 1536 SFT - is the service function type. 1538 Value ordering: SPI, then SI, then SFT (lowest to highest) 1540 Conflicts/Interactions: Any redirection or traffic sampling found in: 1542 Traffic Action (action 0x07) , 1544 Redirect to IPv4 (action 0x08 (8)), 1545 Redirect to IPv6 (action 0xOD (13)) 1547 Redirect to Indirection-ID (action 0xF (15) 1549 Reference: [RFC9015] 1551 3.2.10. Flow Specification Redirect to Indirection-ID (RDIID) (15, 1552 0x0F) 1554 SubTLV: 15 (0x0F) 1556 note: current value is 0x00 for FSv1 1558 Length: 6 octets 1560 Value field: 1562 [Flags (1 octet)] [ID-Type (1 octet)][Generalized-ID (4 octets)] 1564 Figure 3-17 1566 where: 1568 Flags: are defined as: 1570 - [S-ID]: sequence number for indirection IDs (3 bits). 1572 o Value of zero means sequence is not set and all other S-ID 1573 values should be ignored 1575 - [C] - copy packets matching this ID 1577 ID-Type: type of indirection ID with following values: 1579 - 0 - localized ID 1581 - 1 - Node with SID/index in MPLS SR 1583 - 2 - Node with SID/label in MPLS SR 1585 - 3 - Node with Binding Segment ID with SID/Index 1587 - 4 - Node with Binding Segment ID with SID/Label 1589 - 5 - Tunnel ID 1591 Generalized-ID (G-ID): indirection value 1593 Value Ordering: first indirection ID, then Generalized ID 1595 Action Value ordering: ID-Type by value (lowest to highest) 1597 Conflicts/Interactions: Any redirection or traffic sampling found in: 1599 Traffic Action (action 0x07), 1601 Redirect to IPv4 (action 0x08 (8)), 1603 Redirect to IPv6 (action 0x0D, (13) 1605 Redirect to SFC (action 0xOE (14)) 1607 reference: [I-D.ietf-idr-flowspec-path-redirect] 1609 3.2.11. MPLS Label Action (MPLSLA)(16, 0x10) 1611 Function: MPLS Label actions 1613 SubTLV: 16 (0x10) 1615 Length: 6 octets 1617 Value: 1619 [action (1 octet) 1621 [order (1 octet) 1623 [Label Stack Entry (4 octets)] 1625 where Action: 1627 +------+------------------------------------------------------------+ 1628 |Action| Function | 1629 +------+------------------------------------------------------------+ 1630 | 0 | Push the MPLS tag | 1631 +------+------------------------------------------------------------+ 1632 | 1 | Pop the outermost MPLS tag in the packet | 1633 +------+------------------------------------------------------------+ 1634 | 2 | Swap the MPLS tag with the outermost MPLS tag in the packet| 1635 +------+------------------------------------------------------------+ 1636 | 3~15 | Reserved | 1637 +------+------------------------------------------------------------+ 1639 Figure 3-18 1641 0 1 2 3 1642 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 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Label | Exp |S| TTL | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 Figure 3-19 - Label Stack Entry 1649 Action Value ordering: ID-Type, then value (lowest to highest) 1651 Value Ordering: order, action, label, Exp 1653 Conflicts/Interactions: Any redirection for IP before MPLS 1655 Traffic Action (action 0x07), 1657 Redirect to IPv4 (action 0x08 (8)), 1659 Redirect to IPv6 (action 0x0D, (13) 1661 Redirect to SFC (action 0xOE (14)) 1663 reference: [I-D.ietf-idr-bgp-flowspec-label] 1665 3.2.12. VLAN action (VLAN) (22, 0x16) 1667 Function: Rewrite inner or outer VLAN header 1669 SubTLV: 22 (0x16) 1671 Length: 6 octets 1673 Value: 1675 [Rewrite-actions (2 octets)] 1677 [vlan-PCP-DE-1 (2 octets)] 1679 [vlan-PCP-DE-2 [2 octets)] 1681 where: 1683 Rewrite-actions - is as follows: 1685 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 1686 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1687 |PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv | 1688 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1690 Figure 3-20 1692 PO1: Pop action. If the PO1 flag is one, it indicates the 1693 outermost VLAN should be removed. 1695 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 1696 added, the associated Priority Code Point (PCP and Drop 1697 Eligibility Indicator (DEI) are PCP1 and DE1. 1699 SW1: Swap action. If the SW1 flag is one, it indicates the outer 1700 VLAN and inner VLAN should be swapped. 1702 PO2: Pop action. If the PO2 flag is one, it indicates the 1703 outermost VLAN should be removed. 1705 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 1706 added, the associated PCP and DEI are PCP2 and DE2. 1708 SW2: Swap action. If the SW2 flag is one, it indicates the outer 1709 VLAN and inner VLAN should be swapped. 1711 RI1 and RI2: Rewrite inner VLAN action. If the RIx flag is one 1712 where "x" is "1" or "2"), it indicates the inner VLAN should be 1713 replaced by a new VLAN where the new VLAN is VLAN IDx and the 1714 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, 1715 the action is to only modify the PCP and DEI value of the inner 1716 VLAN. 1718 RO1 and RO2: Rewrite outer VLAN action. If the ROx flag is one 1719 (where "x" is "1" or "2"), it indicates the outer VLAN should be 1720 replaced by a new VLAN where the new VLAN is VLAN IDx and the 1721 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, 1722 the action is to only modify the PCP and DEI value of the outer 1723 VLAN. 1725 Resv: Reserved for future use. MUST be sent as zero and ignored 1726 on receipt. 1728 Value ordering: rewrite-actions, VLAN1, VLAN2, PCP-DE1, PCP-DE2 1730 Conflicts: TIPD Action 1732 reference: [I-D.ietf-idr-flowspec-l2vpn] 1734 3.2.13. TPID action (TPID) (23, 0x17) 1736 Function: Replace Inner or outer TP 1738 SubTLV: 23 (0x17) 1740 Length: 6 octets 1742 Value: 1744 [Rewrite-actions (2 octets)] 1746 [TP-ID-1 (2 octets)] 1748 [TP-ID-2 (2 octets)] 1750 Where: rewrite-actions are bitmask (2 octets) with 2 actions as 1751 follows: 1753 0 15 1754 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1755 |TI|TO| Resv | 1756 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1758 Figure 3-21 1760 TI: Mapping inner Tag Protocol (TP) ID (typically a VLAN) action. If 1761 the TI flag is one, it indicates the inner TP ID should be replaced 1762 by a new TP ID, the new TP ID is TP ID1. 1764 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 1765 the outer TP ID should be replaced by a new TP ID, the new TP ID is 1766 TP ID2. 1768 Resv: Reserved for future use. MUST be sent as zero and ignored on 1769 receipt 1771 Value Ordering: rewrite-actions, TP-ID-1, TP-ID-2 1773 Conflicts: VLAN action 1775 reference:[I-D.ietf-idr-flowspec-l2vpn] 1777 3.3. Extended Community vs. Action SubTLV formats 1779 The SubTLV format is used for the Wide communities and for the action 1780 subTLVs in the NLRI. 1782 Sub-TLV Action Action SubTLV Extended Community 1783 type Name format format 1784 ======= ===== =============== ==================== 1785 1 ACO type: 1 (0x01) not applicable (n/a) 1786 length:variable 1788 2 TAIS type: 2 (0x02) type: 0x0702 or 0x4702 1789 length:8 length: 6 1790 [4-octet-as] [4-octet-AS] 1791 [group-3-octet] [flags-group] 1792 [flags-1-octet] (2 octets) 1794 3-5 reserved 1796 Sub-TLV Action Action SubTLV Extended Community 1797 type Name format format 1798 ======= ===== =============== ==================== 1799 6 TRB type:6 (0x06) type:8006 1800 length:8 length: 6 octets 1801 [4-byte-AS] [2-byte-AS] 1802 [float (4 octets)] [float (4 octets)] 1804 7 TA type:7 type:8007 1805 length:1 length:6 octets 1806 flags: (1 octet) flags (6 octets) 1808 8 RDIPv4 type:8 type:8008 1809 length: 12 length: 6 octets 1810 [4-byte-AS] [AS-2-octets] 1811 [IPv4-address] [IPv4 address] 1812 type:8108 1813 length: 6 octets 1814 [IPv4 address] 1815 [ID-2 octets] 1816 type:8208 1817 length: 6 octets 1818 [AS-4-octets] 1819 [ID-2-octets] 1821 9 TM type:9 type:8009 1822 length:1 length: 6 octets 1823 DSCP: 1 octet DSCP: 1 octet 1825 10 type:10 (0X0A) TBA 1827 11 type:11 (0x0B) TBA 1829 12 TRP type:12 (0x0C) type: 0x800C 1830 length: 8 octets length: 6 octets 1831 [4-byte-AS] [2-byte-AS] 1832 [float-4-octet] [float-4-octet] 1834 13 RDIPv6 type:13 (0x0D) type:0x000C 1835 length:22 length: 18 octets 1836 [4-byte-AS] [IPv6-address (16)] 1837 [IPv6-address (16)] [local-admin (2)] 1838 [local-admin (2)] 1840 Sub-TLV Action Action SubTLV Extended Community 1841 type Name format format 1842 ======= ===== =============== ==================== 1844 14 TISFC type:14 (0x0E) type: 0xD (FSv1) 1845 type: 0xE (FSv2) 1846 length:6 length:6 1847 SPI (3 octets) SPI (3 octets) 1848 SI (1 octet) SI (1 octet) 1849 SFT (2 octets) SFT (2 octets) 1851 15 RDIID type:15 (0x0F) type: 0900 (FSv1) 1852 length: 6 length 6 1853 flags (1) flags (1) 1854 ID-type (1) ID type (1) 1855 G-ID (4 octets) G-ID (4-octets) 1857 16 MPLSLA type:16 (0x10) 1859 16-21 TBA - 1861 22 VLAN type:22 (0x16) Type: (TBD) 1862 length:6 length:6 1863 [rewrite-action(2)] [rewrite-actions (2)] 1864 [vlan-pcp-de-1 (2)] [vlan-pcp-de-1 (2)] 1865 [vlan-pcp-de-2 (2)] [vlan-pcp-de-2 (2)] 1867 23 TPID type:23 (0x17) Type: (TBD) 1868 length:6 length:6 1870 [rewrite-action(2)] [rewrite-actions (2)] 1871 [TP-ID-1 (2)] [TP-ID-1 (2)] 1872 [TP-ID-2 (2)] [TP-ID-2 (2)] 1874 3.4. L2 Traffic Rules 1876 The format of the L2 header TLV value field is shown in Figure 3-22. 1877 The AFI/SAFI field includes the AFI (2 octets), SAFI (1 octet). 1879 +-------------------------------+ 1880 | +--------------------------+ | 1881 | | AFI/SAFI field (3) | | 1882 | +--------------------------+ | 1883 | | L3 AFI (2) | | 1884 | +--------------------------+ | 1885 | | L2 filter length (2) | | 1886 | +--------------------------+ | 1887 | | (SubTLVs)+ (L2 then L3) | | 1888 | +--------------------------+ | 1889 +-------------------------------+ 1890 Figure 3-22 -L2 Header TLV value 1892 Where: 1894 AFI/SAFI field has AFI is 6 (IEEE 802) and SAFI is TBD1. 1896 L3 AFI is zero if the filter test only L2 fields, otherwise it is 1897 or 2 depending on whether the filter L3 tests after the L2 header 1898 are for IPv4 or IPv6. 1900 L2 filter length is the length of the L2 SubTLVs in bytes. These 1901 are followed by the L3 SubTLVs is the L3 AFI field is non-zero. 1903 Each L2 SubTLV has the format shown in Figure 3-23. (The L3 SubTLVs 1904 are as defined in Section 4.1.) 1906 Each SubTLV has the format: 1908 +-------------------------------+ 1909 | SubTLV type (1 octet) | 1910 +-------------------------------+ 1911 | length (1 octet) | 1912 + ------------------------------+ 1913 | value (variable) | 1914 +-------------------------------+ 1915 Figure 3-23 1917 SubTLV type: A component type value defined in the "L2 Flow 1918 Specification Component Types" registry for L2 by [draft-ietf-idr- 1919 flowspec-l2vpn). 1921 Where the SubTLVs have the following component types: 1923 Component Types Table 1925 Component 1926 type Description 1927 ======= ================== 1928 1 EtherType 1929 2 Source MAC 1930 3 Destination MAC 1931 4 DSAP (destination service access point) 1932 5 SSAP (source service access point) 1933 6 control field in LLC 1934 7 SNAP 1935 8 VLAN ID 1936 9 VPAN PCP 1937 10 Inner VLAN ID 1938 11 Inner VLAN PCP 1939 12 VLAN DEI 1940 13 VLAN DEI 1941 14 Source MAC special bits 1942 15 Destination MAC special bits 1944 Table 4 – L2 VPN components 1946 See [I-D.ietf-idr-flowspec-l2vpn] for the details on the format and 1947 value fields for each component. 1949 Value ordering: Ordering of L2 FSv2 rules will be by user-defined 1950 order of the rule. For FSv2 filters within the same rule, the 1951 ordering will be by component number and then by value within the 1952 component. See [I-D.ietf-idr-flowspec-l2vpn] for the ordering of the 1953 values within the component. 1955 L2 VPN filtering using SAFI TBD2 is specified in section 3.6. 1957 reference: [I-D.ietf-idr-flowspec-l2vpn] 1959 3.5. SFC Traffic Rules 1961 The FSv2 filters allow for filtering of the SFC NLRI family of 1962 routes. The traffic NLRIs filtered are from SFC AFI/SAFI (AFI = 31, 1963 SAFI=9). 1965 The FSv2 filters provide this filtering with SFC AFI (AFI=31) and 1966 SAFI for FSv2 filters (SAFI = TB1). 1968 +--------------------------------------+ 1969 | +---------------------------------+ | 1970 | | Tunneled AFI/SAFI field | | 1971 | +---------------------------------+ | 1972 | | | | 1973 | | + | | 1974 | +---------------------------------+ | 1975 +--------------------------------------+ 1977 Figure 3-24 1979 Each SubTLV has the format: 1981 +-------------------------------+ 1982 | SubTLV type (1 octet) | 1983 +-------------------------------+ 1984 | length (1 octet) | 1985 + ------------------------------+ 1986 | value (variable) | 1987 +-------------------------------+ 1988 Figure 3-25 – Tunneled SubTLV format 1990 The components listed are: 1992 1 = SFIR RD Type (types 1, 2, 3) 1993 2 = SFIR RD Value 1994 3 = SFIR Pool ID 1995 4 = SFIR MPLS context/label 1996 5 = SFPR SPI 1997 6 = SPF attribute fields 1999 Table 6 – SFC Filter types 2001 Ordering is by: User-defined rule order, component number, and then 2002 value within component. 2004 reference: [RFC9015], [TBD] 2006 3.6. BGP/MPLS VPN IP Traffic Rules 2008 The format of the match filter for BGP/MPLS VPN IP traffic is very 2009 similar to the format for non-VPN IP traffic as defined in 2010 Section 3.1 except that the SAFI is TBD2 and the initial NLRI header 2011 has an 8-byte Route Distinguisher added to it as shown in 2012 Figure 3-26. The SubTLV format and filter components formats remain 2013 the same. 2015 +-------------------------------+ 2016 | +--------------------------+ | 2017 | | AFI/SAFI field (3) | | 2018 | +--------------------------+ | 2019 | | Route Distinguisher (8) | | 2020 | +--------------------------+ | 2021 | | (subTLVs)+ | | 2022 | +--------------------------+ | 2023 +-------------------------------+ 2025 Figure 3-26: VPN IP Filter Header 2027 3.7. BGP/MPLS VPN L2 Traffic Rules 2029 The format of the match filter for BGP/MPLS VPN IP traffic is very 2030 similar to the format for non-VPN L2 traffic as defined in 2031 Section 3.4 except that the SAFI is TBD2 and the initial NLRI header 2032 has an 8-byte Route Distinguisher added to it right after the AFI/ 2033 SAFI as shown in Figure 3-27 The SubTLV format and filter components 2034 formats remain the same. 2036 +-------------------------------+ 2037 | +--------------------------+ | 2038 | | AFI/SAFI field (3) | | 2039 | +--------------------------+ | 2040 | | Route Distinguisher (8) | | 2041 | +--------------------------+ | 2042 | | L3 AFI (2) | | 2043 | +--------------------------+ | 2044 | | L2 filter length (2) | | 2045 | +--------------------------+ | 2046 | | (subTLVs)+ | | 2047 | +--------------------------+ | 2048 +-------------------------------+ 2050 Figure 3-27: VPN L2 Filter Header 2052 3.8. Encoding of Actions passed in Wide Communities 2054 The BGP FSv2 actions are passed in a Wide Community attribute with a 2055 BGP Wide Community container (type 01) 2056 [I-D.ietf-idr-wide-bgp-communities] with community of FSv2 Actions 2057 (TBD4) and Wide Community attributes of Target TLV, Exclude TLVs, and 2058 Parameter TLVs. The Parameter MUST contains an FSv2 Atom which 2059 contains a sequence of Action TLVs. 2061 BGP Wide Community Container 2062 with FSv2 actions 2064 +----------------------------+ 2065 | Community: FSv2-actions | 2066 | (community value = TBD4) | 2067 +----------------------------+ 2068 | Source AS number | 2069 +----------------------------+ 2070 | Context AS number | 2071 +----------------------------+ 2072 | Target or Exclude TLVs + 2073 | (optional) | 2074 +----------------------------+ 2075 | Parameter TLV with | 2076 | FSv2 atom | 2077 +----------------------------+ 2078 figure 3-28 - BGP 2080 +----------------------------+ 2081 | FSv2 Actions atom-id | 2082 +----------------------------+ 2083 | length (2 octets) | 2084 +----------------------------+ 2085 | + | 2086 +----------------------------+ 2088 Figure 3-29 - Flow Specification 2089 with IDs for Wide Community Actions 2091 where: 2093 Atom-id: (TBD5) 2095 length: variable depending on SubTLVS 2097 Action Sub-TLVs as defined above 2099 4. Validation of FSv2 NLRI 2101 The validation of FSv2 NLRI adheres to the combination of rules for 2102 general BGP FSv1 NLRI found in [RFC8955], [RFC8956], [RFC9117], and 2103 the specific additions made for SFC NLRI [RFC9015], and L2VPN NLRI 2104 [I-D.ietf-idr-flowspec-l2vpn]. 2106 To provide clarity, the full validation process for flow 2107 specification routes (FSv1 or FSv2) is described in this section 2108 rather than simply referring to the relevant portions of these RFCs. 2109 Validation only occurs after BGP UPDATE message reception and the 2110 FSv2 NLRI and the path attributes relating to FSv2 (Extended 2111 community and Wide Community) have been determined to be well-formed. 2112 Any MALFORMED FSv2 NRLI is handled as a "TREAT as WITHDRAW" 2113 [RFC7606]. 2115 4.1. Validation of FS NLRI (FSv1 or FSv2) 2117 Flow specifications received from a BGP peer that are accepted in the 2118 respective Adj-RIB-In are used as input to the route selection 2119 process. Although the forwarding attributes of the two routes for 2120 tbe same prefix may be the same, BGP is still required to perform its 2121 path selection algorithm in order to select the correct set of 2122 attributes to advertise. 2124 The first step of the BGP Route selection procedure (section 9.1.2 of 2125 [RFC4271] is to exclude from the selection procedure routes that are 2126 considered unfeasible. In the context of IP routing information, 2127 this is used to validate that the NEXT_HOP Attribute of a given route 2128 is resolvable. 2130 The concept can be extended in the case of the Flow Specification 2131 NLRI to allow other validation procedures. 2133 The FSv2 validation process validates the FSv2 NLRI with following 2134 unicast routes received over the same AFI (1 or 2) but different 2135 SAFIs: 2137 * Flow specification routes (FSv1 or FSv2) received over SAFI=133 2138 will be validated against SAFI=1, 2140 * Flow Specification routes (FSv1 or FSv2) received over SAFI=134 2141 will be validated against SAFI=128, and 2143 * Flow Specification routes (FSv1 or FSv2) [AFI =1, 2] received over 2144 SAFI=77 will be validated using only the Outer Flow Spec against 2145 SAFI = 133. 2147 The FSv2 validates L2 FSv2 NLRI with the following L2 routes received 2148 over the same AFI (25), but a different SAFI: 2150 * Flow specification routes (FSv1 or FSv2)received over SAFI=135 are 2151 validated against SAFI=128. 2153 In the absence of explicit configuration, a Flow specification NLRI 2154 (FSv1 or FSv2) MUST be validated such that it is considered feasible 2155 if and only if all of the conditions are true: 2157 a) A destination prefix component is embedded in the Flow 2158 Specification, 2160 b) One of the following conditions holds true: 2162 - 1. The originator of the Flow Specification matches the 2163 originator of the best-math unicast route for the destination 2164 prefix embedded in the flow specification (this is the unicast 2165 route with the longest possible prefix length covering the 2166 destination prefix embedded in the flow specification). 2168 - 2. The AS_PATH attribute of the flow specification is empty or 2169 contains only an AS_CONFED_SEQUENCE segment [RFC5065]. 2171 o 2a.This condition should be enabled by default. 2173 o 2b.This condition may be disabled by explicit configuration 2174 on a BGP Speaker, 2176 o 2c.As an extension to this rule, a given non-empty AS_PATH 2177 (besides AS_CONFED_SEQUENCE segments) MAY be permitted by 2178 policy]. 2180 c) There are no "more-specific" unicast routes when compared with 2181 the flow destination prefix that have been received from a 2182 different neighbor AS than the best-match unicast route, which has 2183 been determined in rule b. 2185 However, part of rule a may be relaxed by explicit configuration, 2186 permitting Flow Specifications that include no destination prefix 2187 component. If such is the case, rules b and c are moot and MUST be 2188 disregarded. 2190 By "originator" of a BGP route, we mean either the address of the 2191 originator in the ORIGINATOR_ID Attribute [RFC4456] or the source 2192 address of the BGP peer, if this path attribute is not present. 2194 A BGP implementation MUST enforce that the AS in the left-most 2195 position of the AS_PATH attribute of a Flow Specification Route (FSv1 2196 or FSv2) received via the Exterior Border Gateway Protocol (eBGP) 2197 matches the AS in the left-most position of the AS_PATH attribute of 2198 the best-match unicast route for the destination prefix embedded in 2199 the Flow Specification (FSv1 or FSv2) NLRI. 2201 The best-match unicast route may change over time independently of 2202 the Flow Specification NLRI (FSv1 or FSv2). Therefore, a 2203 revalidation of the Flow Specification MUST be performed whenever 2204 unicast routes change. Revalidation is defined as retesting rules a 2205 to c as described above. 2207 4.2. Validation of Flow Specification Actions 2209 Flow Specifications may be mapped to actions using Extended 2210 Communities or a Wide Communities. The FSv2 actions in Extended 2211 Communities and Wide communities can be associated with large number 2212 of NLRIs. 2214 The ordering of precedence for these actions in the case when the 2215 user-defined order is the same follows the precedence of the FSv2 2216 NLRI action TLV values (lowest to highest). User-defined order is 2217 the same when the order value for action is the same. All Extended 2218 Community actions MUST be translated to the user-defined order data 2219 format for internal comparison. By default, all Extended Community 2220 actions SHOULD be translated to a single value. 2222 Actions may conflict, duplicate, or complement other actions. An 2223 example of conflict is the packet rate limiting by byte and by 2224 packet. An example of a duplicate is the request to copy or sample a 2225 packet under one of the redirect functions (RDIPv4, RDIPv6, RDIID, ) 2226 Each FSv2 actions in this document defines the potential conflicts or 2227 duplications. Specifications for new FSv2 actions outside of this 2228 specification MUST specify interactions or conflicts with any FSv2 2229 actions (that appear in this specification or subsequent 2230 specifications). 2232 Well-formed syntactically correct actions should be linked to a 2233 filtering rule in the order the actions should be taken. If one 2234 action in the ordered list fails, the default procedure is for the 2235 action process for this rule to stop and flag the error via system 2236 management. By explicit configuration, the action processing may 2237 continue after errors. 2239 Implementations MAY wish to log the actions taken by FS actions (FSv1 2240 or FSv2). 2242 4.3. Error handling and Validation 2244 The following two error handling rules must be followed by all BGP 2245 speakers which support FSv2: 2247 * FSv2 NLRI having TLVs which do not have the correct lengths or 2248 syntax must be considered MALFORMED. 2250 * FSv2 NLRIs having TLVs which do not follow the above ordering 2251 rules described in section 4.1 MUST be considered as malformed by 2252 a BGP FSv2 propagator. 2254 The above two rules prevent any ambiguity that arises from the 2255 multiple copies of the same NLRI from multiple BGP FSv2 propagators. 2257 A BGP implementation SHOULD treat such malformed NLRIs as 'Treat-as- 2258 withdraw' [RFC7606] 2260 An implementation for a BGP speaker supporting both FSv1 and FSv2 2261 MUST support the error handling for both FSv1 and FSv2. 2263 5. Ordering for Flow Specification v2 (FSv2) 2265 Flow Specification v2 allows the user to order flow specification 2266 rules and the actions associated with a rule. Each FSv2 rule has one 2267 or more match conditions and one or more actions associated with that 2268 match condition. 2270 This section describes how to order FSv2 filters received from a peer 2271 prior to transmission to another peer. The same ordering should be 2272 used for the ordering of forwarding filtering installed based on only 2273 FSv2 filters. 2275 Section 7.0 describes how a BGP peer that supports FSv1 and FSv2 2276 should order the flow specification filters during the installation 2277 of these flow specification filters into FIBs or firewall engines in 2278 routers. 2280 The BGP distribution of FSv1 NLRI and FSv2 NLRI and their associated 2281 path attributes for actions (Wide Communities and Extended 2282 Communities) is "ships-in-the-night" forwarding of different AFI/SAFI 2283 information. This recommended ordering provides for deterministic 2284 ordering of filters sent by the BGP distribution. 2286 5.1. Ordering of FSv2 NLRI Filters 2288 The basic principles regarding ordering of rules are simple: 2290 1) Rule-0 (zero) is defined to be 0/0 with the "permit-all" action 2292 - BGP peers which do not support flow specification permit 2293 traffic for routes received. Rule-0 is defined to be "permit- 2294 all" for 0/0 which is the normal case for filtering for routes 2295 received by BGP. 2297 - By configuration option, the "permit-all" may be set to "deny- 2298 all" if traffic rules on routers used as BGP must have a 2299 "route" AND a firewall filter to allow traffic flow. 2301 2) FSv2 rules are ordered based on the user-defined order numbers 2302 specified in the FSv2 NLRI (rules 1-n). 2304 3) If multiple FSv2 NLRI have the same user-defined order, then 2305 the filters are ordered by type of FSv2 NRLI filters (see Table 1, 2306 section 4) with lowest numerical number have the best precedence. 2308 - For the same user-defined order and the same value for the FSv2 2309 filters type, then the filters are ordered by FSv2 the 2310 component type for that FSv2 filter type (see Tables 3-6) with 2311 the lowest number having the best precedence. 2313 - For the same user-defined order, the same value of FSv2 Filter 2314 Type, and the same value for the component type, then the 2315 filters are ordered by value within the component type. Each 2316 component type defines value ordering. 2318 - For component types inherited from the FSv1 component types, 2319 there are the following two types of comparisons: 2321 o FSv1 component value comparison for the IP prefix values, 2322 compares the length of the two prefixes. If the length is 2323 different, the longer prefix has precedence. If the length 2324 is the same, the lower IP number has precedence. 2326 o For all other FSv1 component types, unless specified, the 2327 component data is compared using the memcmp() function 2328 defined by [ISO_IEC_9899]. For strings with the same 2329 length, the lowest string memcmp() value has precedence. 2330 For strings of different lengths, the common prefix is 2331 compared. If the common string prefix is not equal, then 2332 the string with the lowest string prefix has higher 2333 precedence. If the common prefix is equal, the longest 2334 string is considered to have higher precedence 2336 Notes: 2338 * Since the user can define rules that re-order these value 2339 comparisons, this order is arbitrary and set to provide a 2340 deterministic default. 2342 5.2. Ordering of the Actions 2344 The FSv2 specification allows for actions to be associated by: 2346 a) a Wide Community path attribute, or 2348 b) an Extended Community path attribute. 2350 Actions may be ordered by user-defined action order number from 1-n 2351 (where n is 2**16-2 and the value 2**16-1 is reserved. 2353 Byy default, extended community actions are associated with default 2354 order number 32768 [0x8000] or a specific configured value for the 2355 FSv2 domain. 2357 Action user-order number zero is defined to have an Action type of 2358 "Set Action Chain operation" (ACO) (value 0x01) that defines the 2359 default action chain process. For details on "set action chain 2360 operation" see section 3.2.1 or section 5.2.1 below. 2362 If the user-defined action number for two actions are the same, then 2363 the actions are ordered by FSv2 action types (see Table 3 for a list 2364 of action types). If the user-defined action number and the FSv2 2365 action types are the same, then the order must be defined by the FSv2 2366 action. 2368 5.2.1. Action Chain Operation (ACO) 2370 The "Action Chain Operation" (ACO) changes the way the actions after 2371 the current action in an action chain are handled after a failure. 2372 If no action chain operations are set, then the default action of 2373 "stop upon failure" (value 0x00) will be used for the chain. 2375 5.2.1.1. Example 1 - Default ACO 2377 Use Case 1: Rate limit to 600 packets per second 2379 Description: The provider will support 600 packets per second All 2380 Packets sampled for reporting purposes and packet streams over 600 2381 packets per second will be dropped. 2383 Suppose BGP Peer A has a 2384 * a Wide Community action with user-defined order 10 with Traffic 2385 Sampling 2387 * a Wide Community action with user-defined order 11 from AS 2020 2388 that limits packet-based rate limit of 600 packets per second. 2390 * an Extended Community from AS 2020 that does limits packet-based 2391 rate limit of 50 packets per second. 2393 The FSv2 data base would store the following action chain: 2395 * at user-defined action order 10 2397 - A user action of type 7 (traffic action) with values of 2398 Sampling and logging. 2400 * at user-defined action order 11 2402 - a user action type of 12 (packet-based rate limit) with values 2403 of AS 2020 and float value for 600 packets per second (pps) 2405 * at user-defined action order 32768 (0x8000) with type 12 and 2406 values of A user action of type 12 with values of AS 2020 and 2407 float value of 50 packets/second. 2409 Normal action: 2411 The match on the traffic would cause a sample of the traffic 2412 (probably with packet rate saved in logging) followed by a rate 2413 limit to 600 pps. The Extended community action would further 2414 limit the rate to 50 packets per second. 2416 When does the action chain stop? 2418 The default process for the action chain is to stop on failure. 2419 If there is no failure, then all three actions would occur. This 2420 is probably not what the user wants. 2422 If there is failure at action 10 (sample and log), then there 2423 would be no rate limiting per packet (actions 11 and action 2424 32768). 2426 If there is failure at action 11 (rate limit to packet 600), then 2427 there would be no rate limiting per packet (action 32768). 2429 The different options for Action chain ordering (ACO) have been 2430 worked on with NETCONF/RESTCONF configuration and actions. 2432 5.2.1.2. Example 2: Redirect traffic over limit to processing via SFC 2434 Use case 2: Redirect traffic over limit to processing via SFC. 2436 Description: The normal function is for traffic over the limit to be 2437 forwarded for offline processing and reporting to a customer. 2439 Suppose we have the following 4 actions defined for a match: 2441 * Sent Redirect to indirection ID (0x01) with user-defined match 2 2442 attached in wide community, 2444 * Traffic rate limit by bytes (0x07) with user-defined match 1 2445 attached in wide community, 2447 * Traffic sample (0x07) sent in extended community, and 2449 * SF classifier Info (0x0E) sent in extended community. 2451 These 4 filters rate limit a potential DDoS attack by: a) redirect 2452 the packet to indirection ID (for slower speed processing), sample to 2453 local hardware, and forward the attack traffic via a SFC to a data 2454 collection box. 2456 The FSv2 action list for the match would look like this 2458 Action 0: Operation of action chain (0x01) (stop upon failure) 2460 Action 1: Traffic Rate limit by byte (0x07) 2462 Action 2: Redirect to Redirection ID (0x0F) 2464 Action 32768 (0x8000) Traffic Action (0x07) Sample 2466 Action 32768 (0x8000) SFC Classifier: (0xE) 2468 If the redirect to a redirection ID fails, then Traffic Sample and 2469 sending the data to an SFC classifier for forwarding via SFC will not 2470 happen. The traffic is limited, but not redirect away from the 2471 network and a sample sent to DDOS processing via a SFC classifier. 2473 Suppose the following 5 actions were defined for a FSV2 filter: 2475 * Set Action Chain Operation (ACO) (0x01) to continue on failure 2476 (ox01) at user-order 2 attached in wide community, 2478 * redirect to indirection ID (0x0F) at user-order 2 attached in wide 2479 community, 2481 * traffic rate limit by bytes (0x07)with user-order 1 attached in 2482 wide community, 2484 * Traffic sample (0x07) attached via extended community, and 2486 * SFC classifier Info (0x0E) attached in extended community. 2488 The FSv2 action list for the match would look like this: 2490 Action 00: Operation of action chain (0x01) (stop upon failure) 2492 Action 01:Traffic Rate limit by byte (0x07) 2494 Action 02:Set Action Chain Operation (ACO) (0x01) (continue on 2495 failure) 2497 Action 02: Redirect to Redirection ID (0F) 2499 Action 32768 (0x8000): Traffic Action (0x07) Sample 2501 Action 32768 (0x8000): SFC classifier (0x0E) forward via SFC [to 2502 DDoS classifier] 2504 If the redirect to a redirection ID fails, the action chain will 2505 continue on to sample the data and enact SFC classifier actions. 2507 5.2.2. Summary of FSv2 ordering 2509 Operators should use user-defined ordering to clearly specify the 2510 actions desired upon a match. The FSv2 actions default ordering is 2511 specified to provide deterministic order for actions which have the 2512 same user-defined order and same type. 2514 FS Action Value Order 2515 (lowest value to highest) (lowest to highest) 2516 ================================ ============================== 2517 0x01: ACO: Action chain operation Failure flag 2518 0x02: TAIS:Traffic actions per AS, then Group-ID, then Action ID 2519 Interface group 2521 0x03-0x05 to be assigned TBD 2522 0x06: TRB: Traffic rate limit AS, then float value 2523 by bytes 2524 0x07: TA: Traffic Action traffic action value 2525 0x08: RDIP: Redirect to IP AS, then IP Address, then ID 2526 0x09: TM: Traffic Marking DSCP value (lowest to highest) 2527 0x0A: AL2: Associated L2 Info. TBD 2528 0x0B: AET: Associated E-tree Info. TBD 2529 0x0C: TRP: Traffic Rate limit AS, then float value 2530 by bytes 2531 0x0D: RDIPv6: Traffic 2532 Redirect to IPv6 AS, IPv6 value, then local Admin 2533 0x0E: TISFC: Traffic insertion 2534 to SFC SPI, then SI, the SFT 2535 0xOF: Redirect to 2536 Indirection-ID ID-type, then Generalized-ID 2538 0x10: MPLSLA: MPLS Label stack order, action, label, Exp 2539 0x16 – VLAN action rewrite-actions, VALN1, VLAN2, 2540 PCP-DE1, PCP-DE2 2541 0x17 – TPID action rewrite actions, TP-ID-1, TP-ID-2 2543 Figure 6-1 2545 6. Ordering of FS filters for BGP Peers support FSv1 and FSv2 2547 FSv2 allows the user to order flow specification rules and the 2548 actions associated with a rule. Each FSv2 rule has one or more match 2549 conditions and one or more actions associated with each rule. 2551 FSv1 and FSv2 filters are sent as different AFI/SAFI pairs so FSv1 2552 and FSv2 operate as ships-in-the-night. Some BGP peers in an AS may 2553 support both FSv1 and FSv2. Other BGP peers may support FSv1 or 2554 FSv2. Some BGP will not support FSv1 or FSV2. A coherent flow 2555 specification technology must have consistent best practices for 2556 ordering the FSv1 and FSv2 filter rules. 2558 One simple rule captures the best practice: Order the FSv1 filters 2559 after the FSv2 filter by placing the FSv1 filters after the FSv2 2560 filters. 2562 To operationally make this work, all flow specification filters 2563 should be included the same data base with the FSv1 filters being 2564 assigned a user- defined order beyond the normal size of FSv2 user- 2565 ordered values. A few examples, may help to illustrate this best 2566 practice. 2568 Example 1: User ordered numbering - Suppose you might have 1,000 2569 rules for the FSv2 filters. Assign all the FSv1 user defined rules 2570 to 1,001 (or better yet 2,000). The FSv1 rules will be ordered by 2571 the components and component values. 2573 Example 2: Storage of actions - All FSv1 actions are defined ordered 2574 actions in FSv2. Translate your FSv1 actions into FSv2 ordered 2575 actions for storing in a common FSv1-FSv2 flow specification data 2576 base. 2578 Example 3: Mixed Flow Specification Support - 2580 Suppose an FSv2 peer (BGP Peer A) has the capability to send 2581 either FSv1 or FSv2. BGP Peer A peers with BGP Peers B, C, D and 2582 E. 2584 BGP Peer B can only send FSv1 routes (NLRI + Extended Community). 2585 BGP Peer C can send FSv2 routes (NLRI + path attributes (wide 2586 community or extended community or none)). BGP Peer D cannot send 2587 any FS routes. BGP E can send FSv2 and FSv1 routes 2589 BGP Peer A sends FSv1 routes in its databases to BGP B. Since the 2590 FSv2 NLRI cannot be sent to the FSv1 peer, only the FSv1 NLRI is 2591 sent. BGP Peer A sends to BGP C the FSv2 routes in its database 2592 (configured or received). 2594 BGP peer A would not send the FSv1 NLRI or FSv2 NLRI to BGP Peer 2595 D. The BGP Peer D does not support for these NLRI. 2597 BGP Peer A sends the NLRI for both FSv1 and FSv2 to BGP Peer E. 2599 +---------+ +---------+ 2600 | A |=======================| C | 2601 |FSv1+FSv2|. . .| FSv2 | 2602 +---------+ . . +---------+ 2603 || | \ . . . || 2604 || | \ . . . . . . . . . . || 2605 || | \ . . . || 2606 || | \-----\ . . . || 2607 || | \ . . . || 2608 +---------+ +------+ +-----+ || 2609 | E |-------| B |. . . .| D | || 2610 |FSv1+FSv2| | FSv1 | |no FS| || 2611 +---------+ +------+ +-----+ || 2612 || . . || 2613 || . . . . . . . . . . . . . . || 2614 || || 2615 |========================================| 2617 Double line = FSv2 2618 Single line = FSv1 2619 Dotted line = BGP peering with no FlowSpec 2621 Figure 6-2: FSv1 and FVs2 Peering 2623 7. Scalability and Aspirations for FSv2 2625 Operational issues drive the deployment of BGP flow specification as 2626 a quick and scalable way to distribute filters. The early operations 2627 accepted the fact validation of the distribution of filter needed to 2628 be done outside of the BGP distribution mechanism. Other mechanisms 2629 (NETCONF/RESTCONF or PCEP) have reply-request protocols. 2631 These features within BGP have not changed. BGP still does not have 2632 an action-reply feature. 2634 NETCONF/RESTCONF latest enhancements provide action/response features 2635 which scale. The combination of a quick distribution of filters via 2636 BGP and a long-term action in NETCONF/RESTCONF that ask for reporting 2637 of the installation of FSv2 filters may provide the best scalability. 2639 The combination of NETCONF/RESTCONF network management protocols and 2640 BGP focuses each protocol on the strengths of scalability. 2642 FSv2 will be deployed in webs of BGP peers which have some BGP peers 2643 passing FSv1, some BGP peers passing FSv2, some BGP peers passing 2644 FSv1 and FSv2, and some BGP peers not passing any routes. 2646 The TLV encoding and deterministic behaviors of FSv2 will not 2647 deprecate the need for careful design of the distribution of flow 2648 specification filters in this mixed environment. The needs of 2649 networks for flow specification are different depending on the 2650 network topology and the deployment technology for BGP peers sending 2651 flow specification. 2653 Suppose we have a centralized RR connected to DDoS processing sending 2654 out flow specification to a second tier of RR who distribute the 2655 information to targeted nodes. This type of distribution has one set 2656 of needs for FSv2 and the transition from FSv1 to FSv2 2658 Suppose we have Data Center with a 3-tier backbone trying to 2659 distribute DDoS or other filters from the spine to combinational 2660 nodes, to the leaf BGP nodes. The BGP peers may use RR or normal BGP 2661 distribution. This deployment has another set of needs for FSv2 and 2662 the transition from FSv1 to FSV2. 2664 Suppose we have a corporate network with a few AS sending DDoS 2665 filters using basic BGP from a variety of sites. Perhaps the 2666 corporate network will be satisfied with FSv1 for a long time. 2668 These examples are given to indicate that BGP FSv2, like so many BGP 2669 protocols, needs to be carefully tuned to aid the mitigation services 2670 within the network. This protocol suite starts the migration toward 2671 better tools using FSv2, but it does not end it. With FSv2 TLVs and 2672 deterministic actions, new operational mechanisms can start to be 2673 understood and utilized. 2675 This FSv2 specification is merely the start of a revolution of work - 2676 not the end. 2678 8. Optional Security Additions 2680 This section discusses the optional BGP Security additions for BGP-FS 2681 v2 relating to BGPSEC [RFC8205] and ROA [RFC6482]. 2683 8.1. BGP FSv2 and BGPSEC 2685 Flow specification v1 ([RFC8955] and [RFC8956]) do not comment on how 2686 BGP Flow specifications to be passed BGPSEC [RFC8205] BGP Flow 2687 Specification v2 can be passed in BGPSEC, but it is not required. 2689 FSv1 and FSv2 may be sent via BGPSEC. 2691 8.2. BGP FSv2 with ROA 2693 BGP FSv2 can utilize ROAs in the validation. If BGP FSv2 is used 2694 with BGPSEC and ROA, the first thing is to validate the route within 2695 BGPSEC and second to utilize BGP ROA to validate the route origin. 2697 The BGP-FS peers using both ROA and BGP-FS validation determine that 2698 a BGP Flow specification is valid if and only if one of the following 2699 cases: 2701 * If the BGP Flow Specification NLRI has a IPv4 or IPv6 address in 2702 destination address match filter and the following is true: 2704 - A BGP ROA has been received to validate the originator, and 2706 - The route is the best-match unicast route for the destination 2707 prefix embedded in the match filter; or 2709 * If a BGP ROA has not been received that matches the IPv4 or IPv6 2710 destination address in the destination filter, the match filter 2711 must abide by the [RFC8955] and [RFC8956] validation rules as 2712 follows: 2714 - The originator match of the flow specification matches the 2715 originator of the best-match unicast route for the destination 2716 prefix filter embedded in the flow specification", and 2718 - No more specific unicast routes exist when compared with the 2719 flow destination prefix that have been received from a 2720 different neighboring AS than the best-match unicast route, 2721 which has been determined in step A. 2723 The best match is defined to be the longest-match NLRI with the 2724 highest preference. 2726 9. IANA Considerations 2728 This section complies with [RFC7153]. 2730 9.1. Flow Specification V2 SAFIs 2732 IANA is requested to assign two SAFI Values in the registry at 2733 https://www.iana.org/assignments/safi-namespace from the Standard 2734 Action Range as follows: 2736 Value Description Reference 2737 ----- ------------- --------------- 2738 TBD1 BGP FSv2 [this document] 2739 TBD2 BGP FSv2 VPN [this document] 2741 9.2. BGP Capability Code 2743 IANA is requested to assign a Capability Code from the registry at 2744 https://www.iana.org/assignments/capability-codes/ from the IETF 2745 Review range as follows: 2747 Value Description Reference Controller 2748 ----- --------------------- --------------- ---------- 2749 TBD3 Flow Specification V2 [this document] IETF 2751 9.3. Filter IP Component types 2753 IANA is requested to indicate [this draft] as a reference on the 2754 following assignments in the Flow Specification Component Types 2755 Registry: 2757 Value Description Reference 2758 ----- ------------------- ------------------------ 2759 1 Destination filter [RFC8955][RFC8956][this document] 2760 2 Source Prefix [RFC8955][RFC8956][this document] 2761 3 IP Protocol [RFC8955][RFC8956][this document] 2762 4 Port [RFC8955][RFC8956][this document] 2763 5 Destination Port [RFC8955][RFC8956][this document] 2764 6 Source Port [RFC8955][RFC8956][this document] 2765 7 ICMP Type [v4 or v6][RFC8955][RFC8956][this document] 2766 8 ICMP Code [v4 or v6][RFC8955][RFC8956][this document] 2767 9 TCP Flags [v4] [RFC8955][RFC8956][this document] 2768 10 Packet Length [RFC8955][RFC8956][this document] 2769 11 DSCP marking [RFC8955][RFC8956][this document] 2770 12 Fragment [RFC8955][RFC8956][this document] 2771 13 Flow Label [RFC8956][this document] 2772 14 TTL [this document] 2773 15 Partial SID [draft-ietf-idr-flowspec-srv6] 2774 [this document] 2775 16 MPLS Label Match 1 [this document] 2776 [draft-ietf-idr-flowspec-mpls-match] 2777 17 MPLS Label Match 2 [this document] 2778 [draft-ietf-idr-flowspec-mpls-match] 2780 9.4. FSV2 NLRI TLV Types 2782 IANA is requested to create the following two new registries on a new 2783 "Flow Specification v2 TLV Types" web page. 2785 Name: BGP FSv2 TLV types 2786 Reference: [this document] 2787 Registration Procedures: 0x01-0x3FFF Standards Action. 2789 Type Use Reference 2790 ----- --------------- --------------- 2791 0x00 Reserved [this document] 2792 0x01 IP traffic rules [this document] 2793 0x02 FSv2 Actions [this document] 2794 0x03 L2 traffic rules [this document] 2795 0x04 tunnel traffic rules [this document] 2796 0x05 SFC AFI filter rules [this document] 2797 0x06 BGP/MPLS VPN IP 2798 traffic rules [this document] 2799 0x07 BGP/MPLS VPN L2 2800 traffic rules [this document] 2801 0x08-0x3FFF Unassigned [this document] 2802 0x4000-0x7FFF Vendor specific [this document] 2803 0x8000-0xFFFF Reserved [this document] 2805 Name: BGP FSv2 Action types 2806 Reference: [this document] 2807 Registration Procedure: 0x01-0x3FFF Standards Action. 2809 Type Use Reference 2810 ----- --------------- --------------- 2811 0x00 Reserved [this document] 2812 0x01 ACO: Action Chain Operation [this document] 2813 0x02 TAIS: Traffic actions per 2814 interface group [this document] 2815 0x03 Unassigned [this document] 2816 0x04 Unassigned [this document] 2817 0x05 Unassigned [this document] 2818 0x06 TRB: traffic rate 2819 limited by bytes [this document] 2820 0x07 TA: Traffic action 2821 (terminal/sample) [this document] 2822 0x08 RDIPv4: redirect IPv4 [this document] 2823 0x09 TM: traffic marking (DSCP) [this document] 2824 0x0A AL2: associate L2 Information [this document] 2825 0x0B AET: associate E-Tree 2826 information [this document] 2827 0x0C TRP: traffic rate 2828 limited by packets [this document] 2829 0x0D RDIPv6: Redirect to IPv6 [this document] 2830 0x0E TISFC: Traffic insertion 2831 to SFC [this document] 2832 0x0F RDIID: Redirect 2833 to indirection-iD [this document] 2834 0x10 MPLS Label Action [this document] 2835 0x11 unassigned [this document] 2836 0x12 unassigned [this document] 2837 0x13 unassigned [this document] 2838 0x14 unassigned [this document] 2839 0x15 unassigned [this document] 2840 0x16 VLAN action [this document] 2841 0x17 TIPD action [this document] 2842 0x18- 2843 0x3ff Unassigned [this document] 2844 0x4000- 2845 0x7fff Vendor assigned [this document] 2846 0x8000- 2847 0xFFFF Reserved [this document] 2849 9.5. Wide Community Assignments 2851 IANA is requested to assign values in the BGP Community Container 2852 Atom Type Registry 2853 Name Type value 2854 ----- ----------- 2855 FSv2 action atom TBD5 2857 IANA is requested to assign values from the Registered Type 1 BGP 2858 Wide Community Types: 2860 Name type Value 2861 ------ ----------- 2862 FSv2 Actions TBD4 2864 10. Security Considerations 2866 The use of ROA improves on [RFC8955] by checking to see of the route 2867 origination. This check can improve the validation sequence for a 2868 multiple-AS environment. 2870 >The use of BGPSEC [RFC8205] to secure the packet can increase 2871 security of BGP flow specification information sent in the packet. 2873 The use of the reduced validation within an AS [RFC9117] can provide 2874 adequate validation for distribution of flow specification within a 2875 single autonomous system for prevention of DDoS. 2877 Distribution of flow filters may provide insight into traffic being 2878 sent within an AS, but this information should be composite 2879 information that does not reveal the traffic patterns of individuals. 2881 11. References 2883 11.1. Normative References 2885 [I-D.ietf-idr-bgp-flowspec-label] 2886 Liang, Q., Hares, S., You, J., Raszuk, R., and D. Ma, 2887 "Carrying Label Information for BGP FlowSpec", Work in 2888 Progress, Internet-Draft, draft-ietf-idr-bgp-flowspec- 2889 label-01, 6 December 2016, 2890 . 2893 [I-D.ietf-idr-flowspec-interfaceset] 2894 Litkowski, S., Simpson, A., Patel, K., Haas, J., and L. 2895 Yong, "Applying BGP flowspec rules on a specific interface 2896 set", Work in Progress, Internet-Draft, draft-ietf-idr- 2897 flowspec-interfaceset-05, 18 November 2019, 2898 . 2901 [I-D.ietf-idr-flowspec-l2vpn] 2902 Hao, W., Eastlake, D. E., Litkowski, S., and S. Zhuang, 2903 "BGP Dissemination of L2 Flow Specification Rules", Work 2904 in Progress, Internet-Draft, draft-ietf-idr-flowspec- 2905 l2vpn-18, 24 October 2021, 2906 . 2909 [I-D.ietf-idr-flowspec-mpls-match] 2910 Yong, L., Hares, S., Liang, Q., and J. You, "BGP Flow 2911 Specification Filter for MPLS Label", Work in Progress, 2912 Internet-Draft, draft-ietf-idr-flowspec-mpls-match-01, 6 2913 December 2016, . 2916 [I-D.ietf-idr-flowspec-nvo3] 2917 Eastlake, D., Weiguo, H., Zhuang, S., Li, Z., and R. Gu, 2918 "BGP Dissemination of Flow Specification Rules for 2919 Tunneled Traffic", Work in Progress, Internet-Draft, 2920 draft-ietf-idr-flowspec-nvo3-15, 6 February 2022, 2921 . 2924 [I-D.ietf-idr-flowspec-path-redirect] 2925 Velde, G. V. D., Patel, K., and Z. Li, "Flowspec 2926 Indirection-id Redirect", Work in Progress, Internet- 2927 Draft, draft-ietf-idr-flowspec-path-redirect-11, 26 May 2928 2020, . 2931 [I-D.ietf-idr-flowspec-srv6] 2932 Li, Z., Li, L., Chen, H., Loibl, C., Mishra, G. S., Fan, 2933 Y., Zhu, Y., and X. Liu, "BGP Flow Specification for 2934 SRv6", Work in Progress, Internet-Draft, draft-ietf-idr- 2935 flowspec-srv6-01, 8 April 2022, 2936 . 2939 [I-D.ietf-idr-wide-bgp-communities] 2940 Raszuk, R., Haas, J., Lange, A., Decraene, B., Amante, S., 2941 and P. Jakma, "BGP Community Container Attribute", Work in 2942 Progress, Internet-Draft, draft-ietf-idr-wide-bgp- 2943 communities-06, 10 January 2022, 2944 . 2947 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2948 DOI 10.17487/RFC0791, September 1981, 2949 . 2951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2952 Requirement Levels", BCP 14, RFC 2119, 2953 DOI 10.17487/RFC2119, March 1997, 2954 . 2956 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 2957 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 2958 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 2959 . 2961 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 2962 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 2963 DOI 10.17487/RFC4271, January 2006, 2964 . 2966 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 2967 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 2968 February 2006, . 2970 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2971 "Multiprotocol Extensions for BGP-4", RFC 4760, 2972 DOI 10.17487/RFC4760, January 2007, 2973 . 2975 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 2976 System Confederations for BGP", RFC 5065, 2977 DOI 10.17487/RFC5065, August 2007, 2978 . 2980 [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route 2981 Origin Authorizations (ROAs)", RFC 6482, 2982 DOI 10.17487/RFC6482, February 2012, 2983 . 2985 [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP 2986 Extended Communities", RFC 7153, DOI 10.17487/RFC7153, 2987 March 2014, . 2989 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 2990 Patel, "Revised Error Handling for BGP UPDATE Messages", 2991 RFC 7606, DOI 10.17487/RFC7606, August 2015, 2992 . 2994 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2995 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2996 May 2017, . 2998 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 2999 Bacher, "Dissemination of Flow Specification Rules", 3000 RFC 8955, DOI 10.17487/RFC8955, December 2020, 3001 . 3003 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 3004 "Dissemination of Flow Specification Rules for IPv6", 3005 RFC 8956, DOI 10.17487/RFC8956, December 2020, 3006 . 3008 [RFC9015] Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 3009 Jalil, "BGP Control Plane for the Network Service Header 3010 in Service Function Chaining", RFC 9015, 3011 DOI 10.17487/RFC9015, June 2021, 3012 . 3014 [RFC9117] Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. 3015 Mohapatra, "Revised Validation Procedure for BGP Flow 3016 Specifications", RFC 9117, DOI 10.17487/RFC9117, August 3017 2021, . 3019 11.2. Informative References 3021 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 3022 and A. Bierman, Ed., "Network Configuration Protocol 3023 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 3024 . 3026 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 3027 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 3028 . 3030 [RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol 3031 Specification", RFC 8205, DOI 10.17487/RFC8205, September 3032 2017, . 3034 [RFC8206] George, W. and S. Murphy, "BGPsec Considerations for 3035 Autonomous System (AS) Migration", RFC 8206, 3036 DOI 10.17487/RFC8206, September 2017, 3037 . 3039 Authors' Addresses 3041 Susan Hares 3042 Hickory Hill Consulting 3043 7453 Hickory Hill 3044 Saline, MI 48176 3045 United States of America 3046 Phone: +1-734-604-0332 3047 Email: shares@ndzh.com 3049 Donald Eastlake 3050 Futurewei Technologies 3051 2386 Panoramic Circle 3052 Apopka, FL 32703 3053 United States of America 3054 Phone: +1-508-333-2270 3055 Email: d3e3e3@gmail.com 3057 Chaitanya Yadlapalli 3058 ATT 3059 United States of America 3060 Email: cy098d@att.com 3062 Sven Maduschke 3063 Verizon 3064 Germany 3065 Email: sven.maduschke@de.verizon.com