idnits 2.17.1 draft-ietf-idr-flowspec-l2vpn-19.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2022) is 737 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: '0x080A' is mentioned on line 710, but not defined == Missing Reference: '0x080B' is mentioned on line 711, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT W. Hao 2 Intended Status: Proposed Standard Huawei Technologies 3 D. Eastlake 4 Futurewei Technologies 5 S. Litkowski 6 Cisco Systems 7 S. Zhuang 8 Huawei Technologies 9 Expires: October 17, 2022 April 18, 2022 11 BGP Dissemination of L2 Flow Specification Rules 12 draft-ietf-idr-flowspec-l2vpn-19 14 Abstract 15 This document defines a Border Gateway Protocol (BGP) Flow 16 Specification (flowspec) extension to disseminate Ethernet Layer 2 17 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering 18 rules either by themselves or in conjunction with L3 flowspecs. 19 AFI/SAFI 6/133 and 25/134 are used for these purposes. New component 20 types and two extended communities are also defined. 22 Status of This Document 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Distribution of this document is unlimited. Comments should be sent 28 to the authors or the IDR Working Group mailing list . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 https://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 42 Shadow Directories can be accessed at 43 https://www.ietf.org/shadow.html. 45 Table of Contents 47 1. Introduction............................................3 48 1.1 Terminology............................................4 50 2. Layer 2 Flow Specification Encoding.....................5 51 2.1 L2 Component Types.....................................6 52 2.1.1 Type 1 - Ethernet Type (EtherType)...................6 53 2.1.2 Type 2 - Source MAC..................................7 54 2.1.3 Type 3 - Destination MAC.............................7 55 2.1.4 Type 4 - DSAP (Destination Service Access Point).....7 56 2.1.5 Type 5 - SSAP (Source Service Access Point)..........7 57 2.1.6 Type 6 - Control field in LLC........................8 58 2.1.7 Type 7 - SNAP........................................8 59 2.1.8 Type 8 - VLAN ID.....................................8 60 2.1.9 Type 9 - VLAN PCP....................................8 61 2.1.10 Type 10 - Inner VLAN ID.............................9 62 2.1.11 Type 11 - Inner VLAN PCP............................9 63 2.1.12 Type 12 - VLAN DEI..................................9 64 2.1.13 Type 13 - Inner VLAN DEI...........................10 65 2.1.14 Type 14 - Source MAC Special Bits..................10 66 2.1.15 Type 15 - Destination MAC Special Bits.............10 67 2.2 Order of Traffic Filtering Rules......................10 69 3. L2VPN Flow Specification Encoding in BGP...............12 70 3.1 Order of L2VPN Filtering Rules........................12 72 4. Ethernet Flow Specification Traffic Actions............13 73 4.1 VLAN-action...........................................13 74 4.2 TPID-action...........................................15 76 5. Flow Spec Validation...................................16 78 6. IANA Considerations....................................17 79 7. Security Considerations................................19 80 8. Acknowledgements.......................................19 81 9. Contributors...........................................19 83 Normative References......................................20 84 Informative References....................................21 86 Authors' Addresses........................................22 88 1. Introduction 90 Border Gateway Protocol (BGP) Flow Specification [RFC8955] (flowspec) 91 is an extension to BGP that supports the dissemination of traffic 92 flow specifications and resulting actions to be taken on packets in a 93 specified flow. It leverages the BGP Control Plane to simplify the 94 distribution of ACLs (Access Control Lists). Using the Flow 95 Specification extension new filter rules can be injected to all BGP 96 peers simultaneously without changing router configuration. A 97 typical application is to automate the distribution of traffic filter 98 lists to routers for DDoS (Distributed Denial of Service) mitigation, 99 access control, and similar applications. 101 BGP Flow Specification [RFC8955] defines a BGP Network Layer 102 Reachability Information (NLRI) format used to distribute traffic 103 flow specification rules. The NLRI for (AFI=1, SAFI=133) specifies 104 IPv4 unicast filtering. The NLRI for (AFI=1, SAFI=134) specifies 105 IPv4 BGP/MPLS VPN filtering [RFC7432]. The Flow Specification match 106 part defined in [RFC8955] only includes L3/L4 information like IPv4 107 source/destination prefix, protocol, ports, and the like, so traffic 108 flows can only be filtered based on L3/L4 information. This has been 109 extended by [RFC8956] to cover IPv6 (AFI=2) L3/L4. 111 Layer 2 Virtual Private Networks (L2VPNs) have been deployed in an 112 increasing number of networks. Such networks also have requirements 113 to deploy BGP Flow Specification to mitigate DDoS attack traffic. 114 Within an L2VPN network, both IP and non-IP Ethernet traffic may 115 exist. For IP traffic filtering, the VPN Flow Specification rules 116 defined in [RFC8955] and/or [RFC8956], which include match criteria 117 and actions, can still be used. For non-IP Ethernet traffic 118 filtering, Layer 2 related information like source/destination MAC 119 and VLAN must be considered. 121 There are different kinds of L2VPN networks like EVPN [RFC7432], BGP 122 VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP) 123 auto discovery [RFC6074]. Because the Flow Specification feature 124 relies on the BGP protocol to distribute traffic filtering rules, it 125 can only be incrementally deployed in those L2VPN networks where BGP 126 has already been used for auto discovery and/or signaling purposes 127 such as BGP-based VPLS [RFC4761], EVPN, and LDP-based VPLS [RFC4762] 128 with BGP auto-discovery [RFC6074]. 130 This document defines new flowspec component types and two new 131 extended communities to support L2 and L2VPN flowspec applications. 132 The flowspec rules can be enforced on all border routers or on some 133 interface sets of the border routers. SAFI=133 in [RFC8955] and 134 [RFC8956] is extended for AFI=6 as specified in Section 2 to cover L2 135 traffic filtering information and in Section 3 SAFI=134 is extended 136 for AFI=25 to cover the L2VPN environment. 138 1.1 Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 The following acronyms and terms are used in this document: 148 AFI - Address Family Identifier 150 ACL - Access Control List 152 DDoS - Distributed Denial of Service 154 DEI - Drop Eligible Indicator 156 EVPN - Ethernet VPN [RFC7432] 158 flowspec - BGP Flow Specification 160 L2 - Layer 2 162 L2VPN - Layer 2 VPN 164 L3 - Layer 3 166 L3VPN - Layer 3 VPN 168 NLRI - Network Layer Reachability Information 170 PCP - Priority Code Point [802.1Q] 172 SAFI - Subsequent Address Family Identifier 174 TPID - Tag Protocol ID, typically a VLAN ID 176 VLAN - Virtual Local Area Network 178 VPLS - Virtual Private Line Service [RFC4762] 180 VPN - Virtual Private Network 182 2. Layer 2 Flow Specification Encoding 184 [RFC8955] defines SAFI 133 and SAFI 134, with AFI=1, for 185 "dissemination of IPv4 flow specification rules" and "dissemination 186 of VPNv4 flow specification rules", respectively. [RFC8956]] extends 187 [RFC8955] to also allow AFI=2 thus making it applicable to both IPv4 188 and IPv6 applications. This document further extends SAFI=133 for 189 AFI=6 and SAFI=134 for AFI=25 to make them applicable to L2 and L2VPN 190 applications. This document also provides for the optional 191 combination of L3 flow specifications with these L2 flow 192 specifications. 194 This section specifies the L2 flowspec for AFI=6/SAFI=133. To 195 simplify assignments, a new registry is used for L2 flowspec. Since 196 it is frequently desirable to also filter on L3/L4 fields, provision 197 is made for their inclusion along with an indication of the L3 198 protocol involved (IPv4 or IPv6). 200 The NLRI part of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 201 a 1- or 2-octet total NLRI length field followed by several fields as 202 described below. 204 +-------------------------------+ 205 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 206 +-------------------------------+ 207 | L3-AFI | 2 octets 208 +-------------------------------+ 209 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 210 +-------------------------------+ 211 | NLRI-value | variable 212 +-------------------------------+ 214 Figure 1: Flow Specification NLRI for L2 216 The fields show in Figure 1 are further specified below: 218 total-length: The length of the subsequent fields (L3 AFI, 219 L2-length, and NRLI-value) encoded as provided in Section 4.1 220 of [RFC8955]. If this field is less than 4, which is the 221 minimum valid value, then the NLRI is malformed in which case a 222 NOTIFICATION message is sent and the BGP connection closed as 223 provided in Section 6.3 of [RFC4271]. 225 L3-AFI: If no L3/L4 filtering is desired, this two octet field 226 MUST be zero which is a reserved AFI value. Otherwise L3-AFI 227 indicates the L3 protocol involved by giving its AFI (0x0001 228 for IPv4 or 0x0002 for IPv6). If the receiver does not 229 understand the value of the L3-AFI field, the MP_REACH or 230 MP_UNREACH attribute is ignored. 232 L2-length: The length of the L2 components at the beginning of the 233 NLRI-value field encoded as provided in Section 4.1 of 234 [RFC8955]. If the value of this field indicates that the L2 235 components extend beyond the total-length, the NLRI is 236 malformed in which case a NOTIFICATION message is sent and the 237 BGP connection closed as provided in Section 6.3 of [RFC4271]. 238 N2-length MAY be zero although, in that case, it would have 239 been more efficient to encode the attribute as an L3 Flow spec 240 unless it is desired to apply an L2 action (see Section 4). A 241 null L2 flowspec always matches. 243 NLRI-value: This consists of the L2 flowspec, of length L2-length, 244 followed by an optionally present L3 flowspec. The result can 245 be treated in most ways as a single flowspec, matching the 246 intersection (AND) of all the components except that the 247 components in the initial L2 region are interpreted as L2 248 components and the remainder as L3 components per the L3-AFI 249 field. This is necessary because there are different registries 250 for the L2, L3 IPv4, and L3 IPv6 component types. If the L3 251 flowspec is null (length zero), it always matches. 253 2.1 L2 Component Types 255 The L2 flowspec portion of the NLRI-value consists of flowspec 256 components as in [RFC8955] but using L2 components and types as 257 specified below. All components start with a type octet followed by a 258 length octet followed by any additional information needed. The 259 length octet gives the length, in octets, of the information after 260 the length octet. This structure applies to all new components to be 261 defined in the L2 Flow-spec Component Registry (see Section 6) and to 262 all existing components except Types 2 and 3 where the length is in 263 bits. 265 2.1.1 Type 1 - Ethernet Type (EtherType) 267 Encoding: 269 Defines a list of {operation, value} pairs used to match the two- 270 octet EtherType field. op is encoded as specified in Section 4.2.1.1 271 of [RFC8955]. Values are encoded as 2-octet quantities. Ethernet II 272 framing defines the two-octet Ethernet Type (EtherType) field in an 273 Ethernet frame, preceded by destination and source MAC addresses, 274 that identifies an upper layer protocol encapsulating the frame data. 275 The match fails if LLC encoding is being used rather than EtherType 276 encoding. 278 2.1.2 Type 2 - Source MAC 280 Encoding: 282 Defines the source MAC Address prefix to match encoded as in BGP 283 UPDATE messages [RFC4271]. Prefix length is in bits and the MAC 284 Prefix is fill out with from 1 to 7 padding bits so that it is an 285 integer number of octets. These padding bits are ignored for matching 286 purposes. 288 2.1.3 Type 3 - Destination MAC 290 Encoding: 292 Defines the destination MAC Address to match encoded as in BGP UPDATE 293 messages [RFC4271]. Prefix length is in bits and the MAC Prefix is 294 fill out with from 1 to 7 padding bits so that it is an integer 295 number of octets. These padding bits are ignored for matching 296 purposes. 298 2.1.4 Type 4 - DSAP (Destination Service Access Point) 300 Encoding: 302 Defines a list of {operation, value} pairs used to match the 1-octet 303 DSAP in the IEEE 802.2 LLC (Logical Link Control Header). Values are 304 encoded as 1-octet quantities. op is encoded as specified in Section 305 4.2.1.1 of [RFC8955]. The match fails if EtherType L2 header encoding 306 is being used rather than LLC encoding. 308 2.1.5 Type 5 - SSAP (Source Service Access Point) 310 Encoding: 312 Defines a list of {operation, value} pairs used to match the 1-octet 313 SSAP in the IEEE 802.2 LLC. Values are encoded as 1-octet 314 quantities. op is encoded as specified in Section 4.2.1.1 of 315 [RFC8955]. The match fails if EtherType L2 header encoding is being 316 used rather than LLC encoding. 318 2.1.6 Type 6 - Control field in LLC 320 Encoding: 322 Defines a list of {operation, value} pairs used to match the 1-octet 323 control field in the IEEE 802.2 LLC. Values are encoded as 1-octet 324 quantities. op is encoded as specified in Section 4.2.1.1 of 325 [RFC8955]. The match fails if EtherType L2 header encoding is being 326 used rather than LLC encoding. 328 2.1.7 Type 7 - SNAP 330 Encoding: 332 Defines a list of {operation, value} pairs used to match 5-octet SNAP 333 (Sub-Network Access Protocol) field. Values are encoded as 8-octet 334 quantities with the zero padded SNAP left justified. op is encoded as 335 specified in Section 4.2.1.1 of [RFC8955]. The match fails if 336 EtherType L2 header encoding is being used rather than LLC encoding. 338 2.1.8 Type 8 - VLAN ID 340 Encoding: 342 Defines a list of {operation, value} pairs used to match VLAN ID. 343 Values are encoded as 2-octet quantities, where the four most 344 significant bits are set to zero and ignored for matching and the 12 345 least significant bits contain the VLAN value. op is encoded as 346 specified in Section 4.2.1.1 of [RFC8955]. 348 In the virtual local-area network (VLAN) stacking case, the VLAN ID 349 is the outer VLAN ID. 351 2.1.9 Type 9 - VLAN PCP 353 Encoding: 355 Defines a list of {operation, value} pairs used to match 3-bit VLAN 356 PCP (priority code point) fields [802.1Q]. Values are encoded using 357 a single octet, where the five most significant bits are set to zero 358 and ignored for matching and the three least significant bits contain 359 the VLAN PCP value. op is encoded as specified in Section 4.2.1.1 of 360 [RFC8955]. 362 In the virtual local-area network (VLAN) stacking case, the VLAN PCP 363 is part of the outer VLAN tag. 365 2.1.10 Type 10 - Inner VLAN ID 367 Encoding: 369 Defines a list of {operation, value} pairs used to match the inner 370 VLAN ID for virtual local-area network (VLAN) stacking or Q-in-Q use. 371 Values are encoded as 2-octet quantities, where the four most 372 significant bits are set to zero and ignored for matching and the 12 373 least significant bits contain the VLAN value. op is encoded as 374 specified in Section 4.2.1.1 of [RFC8955]. 376 In the single VLAN case, this component type MUST NOT be used. If it 377 appears the match will fail. 379 2.1.11 Type 11 - Inner VLAN PCP 381 Encoding: 383 Defines a list of {operation, value} pairs used to match 3-bit inner 384 VLAN PCP fields [802.1Q] for virtual local-area network (VLAN) 385 stacking or Q-in-Q use. Values are encoded using a single octet, 386 where the five most significant bits are set to zero and ignored for 387 matching and the three least significant bits contain the VLAN PCP 388 value. op is encoded as specified in Section 4.2.1.1 of [RFC8955]. 390 In the single VLAN case, this component type MUST NOT be used. If it 391 appears the match will fail. 393 2.1.12 Type 12 - VLAN DEI 395 Encoding: 397 This type tests the DEI (Drop Eligible Indicator) bit in the VLAN 398 tag. If op is zero, it matches if and only if the DEI bit is zero. If 399 op is non-zero, it matches if and only if the DEI bit is one. 401 In the virtual local-area network (VLAN) stacking case, the VLAN DEI 402 is part of the outer VLAN tag. 404 2.1.13 Type 13 - Inner VLAN DEI 406 Encoding: 408 This type tests the DEI bit in the inner VLAN tag. If op is zero, it 409 matches if and only if the DEI bit is zero. If op is non-zero, it 410 matches if and only if the DEI bit is one. 412 In the single VLAN case, this component type MUST NOT be used. If it 413 appears the match will fail. 415 2.1.14 Type 14 - Source MAC Special Bits 417 Encoding: 419 This type tests the bottom nibble of the top octet of the Source MAC 420 address. The two low order bits of that nibble have long been the 421 local bit (0x2) and the group addressed bit (0x1). However, recent 422 changes in IEEE 802 have divided the local address space into 4 423 quadrants specified by the next two bits (0x4 and 0x8) [RFC7042bis]. 424 This flowspec component permits testing, for example, that a MAC is 425 group addressed or is a local address in a particular quadrant. The 426 encoding is as given in Section 4.2.1.2 of [RFC8955]. 428 2.1.15 Type 15 - Destination MAC Special Bits 430 Encoding: 432 As discussed in Section 2.1.14 but for the Destination MAC Address 433 special bits. 435 2.2 Order of Traffic Filtering Rules 437 The existing rules in Section 5.1 of [RFC8955] and in [RFC8956] for 438 the ordering of traffic filtering are extended as follows: 440 L2 flowspecs (AFI = 6, 25) take precedence over L3 flowspecs (AFI = 441 1, 2). Between two L2 flowspecs, precedence of the L2 portion is 442 determined as specified in this section after this paragraph. If the 443 L2 flowspec L2 portions are the same and the L3-AFI is nonzero, then 444 the L3 portions are compared as specified in [RFC8955] or [RFC8956] 445 as appropriate. Note: if the L3-AFI fields are different between two 446 L2 flowspecs, they will never match the same packet so it will not be 447 necessary to prioritize two flowspecs with different L3-AFI values. 449 The original definition for the order of traffic filtering rules can 450 be reused for L2 with new consideration for the MAC Address offset. 451 As long as the offsets are equal, the comparison is the same, 452 retaining longest-prefix-match semantics. If the offsets are not 453 equal, the lowest offset has precedence, as this flow matches the 454 most significant bit. 456 Pseudocode: 457 flow_rule_L2_cmp (a, b) 458 { 459 comp1 = next_component(a); 460 comp2 = next_component(b); 461 while (comp1 || comp2) { 462 // component_type returns infinity on end-of-list 463 if (component_type(comp1) < component_type(comp2)) { 464 return A_HAS_PRECEDENCE; 465 } 466 if (component_type(comp1) > component_type(comp2)) { 467 return B_HAS_PRECEDENCE; 468 } 470 if (component_type(comp1) == MAC_DESTINATION || MAC_SOURCE) { 471 common = MIN(MAC Address length (comp1), 472 MAC Address length (comp2)); 473 cmp = MAC Address compare(comp1, comp2, common); 474 // not equal, lowest value has precedence 475 // equal, longest match has precedence 476 } else { 477 common = 478 MIN(component_length(comp1), component_length(comp2)); 479 cmp = memcmp(data(comp1), data(comp2), common); 480 // not equal, lowest value has precedence 481 // equal, longest string has precedence 482 } 483 } 484 return EQUAL; 485 } 487 3. L2VPN Flow Specification Encoding in BGP 489 The NLRI format for AFI=25/SAFI=134 (L2VPN), as with the other VPN 490 flowspec AFI/SAFI pairs, is the same as the non-VPN Flow-Spec but 491 with the addition of a Route Distinguisher to identify the VPN to 492 which the flowspec is to be applied. 494 In addition, the IANA entry for SAFI 134 is slightly generalized as 495 specified at the beginning of Section 6. 497 The L2VPN NLRI format is as follows: 499 +-------------------------------+ 500 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 501 +-------------------------------+ 502 | Route Distinguisher | 8 octets 503 +-------------------------------+ 504 | L3-AFI | 2 octets 505 +-------------------------------+ 506 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 507 +-------------------------------+ 508 | NLRI-value | variable 509 +-------------------------------+ 511 Figure 2: Flow Specification NLRI for L2VPN 513 The fields in Figure 2, other than the Route Distinguisher, are 514 encoded as specified in Section 2 except that the minimum value for 515 total-length is 12. 517 Flow specification rules received via this NLRI apply only to traffic 518 that belongs to the VPN instance(s) into which it is imported. Flow 519 rules are accepted as specified in Section 5. 521 3.1 Order of L2VPN Filtering Rules 523 The order between L2VPN filtering rules is determined as specified in 524 Section 2.2. Note that if the Route Distinguisher is different 525 between two L2VPN filtering rules, they will never both match the 526 same packet so they need not be prioritized. 528 4. Ethernet Flow Specification Traffic Actions 530 The default action for an L2 traffic filtering flowspec is to accept 531 traffic that matches that particular rule. The following extended 532 community values per [RFC8955] can be used to specify particular 533 actions in an L2 VPN network: 535 +--------+--------------------+----------------------------+ 536 | type | extended community | encoding | 537 +--------+--------------------+----------------------------+ 538 | 0x8006 | traffic-rate | 2-octet as#, 4-octet float | 539 | 0x8007 | traffic-action | bitmask | 540 | 0x8008 | redirect | 6-octet Route Target | 541 | 0x8009 | traffic-marking | DSCP value | 542 +--------+--------------------+----------------------------+ 544 Redirect: The action should be redefined to allow the traffic to be 545 redirected to a MAC or IP VRF routing instance that lists the 546 specified route-target in its import policy. 548 Besides the above extended communities, this document also specifies 549 the following BGP extended communities for Ethernet flows to extend 550 [RFC8955]: 552 +--------+------------------------+--------------------------+ 553 | type | extended community | encoding | 554 +--------+------------------------+--------------------------+ 555 | TBD1 | VLAN-action | bitmask | 556 | TBD2 | TPID-action | bitmask | 557 +--------+------------------------+--------------------------+ 559 4.1 VLAN-action 561 The VLAN-action extended community, as shown in the diagram below, 562 consists of 6 octets that include action Flags, two VLAN IDs, and the 563 associated PCP and DEI values. The action Flags fields are further 564 divided into two parts which correspond to the first action and the 565 second action respectively. Bit 0 to bit 7 give the first action 566 while bit 8 to bit 15 give the second action. The bits of PO, PU, 567 SW, RI and RO in each part represent the action of Pop, Push, Swap, 568 Rewrite inner VLAN and Rewrite outer VLAN respectively. Through this 569 method, more complicated actions also can be represented in a single 570 VLAN-action extended community, such as SwapPop, PushSwap, etc. For 571 example, SwapPop action is the sequence of two actions, the first 572 action is Swap and the second action is Pop. 574 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 575 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 576 |PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv | 577 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 578 | VLAN ID1 | PCP1 |DE1| 579 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 580 | VLAN ID2 | PCP2 |DE2| 581 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 583 PO1: Pop action. If the PO1 flag is one, it indicates the outmost 584 VLAN should be removed. 586 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 587 added, the associated PCP and DEI are PCP1 and DE1. 589 SW1: Swap action. If the SW1 flag is one, it indicates the outer 590 VLAN and inner VLAN should be swapped. 592 PO2: Pop action. If the PO2 flag is one, it indicates the outmost 593 VLAN should be removed. 595 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 596 added, the associated PCP and DEI are PCP2 and DE2. 598 SW2: Swap action. If the SW2 flag is one, it indicates the outer 599 VLAN and inner VLAN should be swapped. 601 RI1 and RI2: Rewrite inner VLAN action. If the RIx flag is one 602 (where "x" is "1" or "2"), it indicates the inner VLAN should be 603 replaced by a new VLAN where the new VLAN is VLAN IDx and the 604 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 605 action is to only modify the PCP and DEI value of the inner VLAN. 607 RO1 and RO2: Rewrite outer VLAN action. If the ROx flag is one 608 (where "x" is "1" or "2"), it indicates the outer VLAN should be 609 replaced by a new VLAN where the new VLAN is VLAN IDx and the 610 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 611 action is to only modify the PCP and DEI value of the outer VLAN. 613 Resv: Reserved for future use. MUST be sent as zero and ignored on 614 receipt. 616 Giving an example below: if the action of PUSH Inner VLAN 10 with PCP 617 value 5 and DEI value 0 and PUSH Outer VLAN 20 with PCP value 6 and 618 DEI value 0 is needed, the format of the VLAN-action extended 619 community is as follows: 621 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 622 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 623 |0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 | 624 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 625 | 10 |1 |0 |1 |0 | 626 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 627 | 20 |1 |1 |0 |0 | 628 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 630 4.2 TPID-action 632 The TPID-action extended community consists of 6 octets which 633 includes the fields of action Flags, TP ID1 and TP ID2. 635 0 15 636 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 637 |TI|TO| Resv | 638 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 639 | TP ID1 | 640 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 641 | TP ID2 | 642 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 644 TI: Mapping inner TP ID action. If the TI flag is one, it indicates 645 the inner TP ID should be replaced by a new TP ID, the new TP ID is 646 TP ID1. 648 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 649 the outer TP ID should be replaced by a new TP ID, the new TP ID is 650 TP ID2. 652 Resv: Reserved for future use. MUST be sent as zero and ignored on 653 receipt. 655 5. Flow Spec Validation 657 Flow Specifications received over AFI=25/SAFI=134 are validated 658 against routing reachability received over AFI=25/SAFI=128 as 659 modified to conform to [RFC9117]. 661 6. IANA Considerations 663 IANA is requested to change the description for SAFI 134 [RFC8955] to 664 read as follows and to change the reference for it to [this 665 document]: 667 134 VPN dissemination of flow specification rules 669 IANA is requested to create an L2 Flow Specification Component Type 670 registry on the Flow Spec Component Types registries web page as 671 follows: 673 Name: L2 Flow Specification Component Types 674 Reference: [this document] 675 Registration Procedures: 676 0 Reserved 677 1-127 Specification Required 678 128-255 First Come First Served 680 Initial contents: 681 +------+-----------------------+------------------------------+ 682 | type | Reference | description | 683 +------+-----------------------+------------------------------+ 684 | 0 | [this document] | Reserved | 685 | 1 | [this document] | Ethernet Type | 686 | 2 | [this document] | Source MAC | 687 | 3 | [this document] | Destination MAC | 688 | 4 | [this document] | DSAP in LLC | 689 | 5 | [this document] | SSAP in LLC | 690 | 6 | [this document] | Control field in LLC | 691 | 7 | [this document] | SNAP | 692 | 8 | [this document] | VLAN ID | 693 | 9 | [this document] | VLAN PCP | 694 | 10 | [this document] | Inner VLAN ID | 695 | 11 | [this document] | Inner VLAN PCP | 696 | 12 | [this document] | VLAN DEI | 697 | 13 | [this document] | Inner VLAN DEI | 698 | 14 | [this document] | Source MAC Special Bits | 699 | 15 | [this document] | Destination MAC Special Bits| 700 |16-254| [this document] | unassigned | 701 | 255 | [this document] | Reserved | 702 +------+-----------------------+------------------------------+ 704 IANA is requested to assign two values from the "BGP Extended 705 Communities Type - extended, transitive" registry [suggested value 706 provided in square brackets]: 708 Type value Name Reference 709 ------------ ------------------------ --------------- 710 TBD1[0x080A] Flow spec VLAN action [this document] 711 TBD2[0x080B] Flow spec TPID action [this document] 713 7. Security Considerations 715 For General BGP Flow Specification Security Considerations, see 716 [RFC8955]. 718 VLAN tagging identifies Layer 2 communities which are commonly 719 expected to be isolated except when higher layer connection is 720 provided, such as Layer 3 routing. Thus, the ability of the flowspec 721 VLAN action to change the VLAN ID in a frame might compromise 722 security. 724 8. Acknowledgements 726 The authors wish to acknowledge the important contributions and 727 suggestions of the following: 729 Hannes Gredler, Xiaohu Xu, Zhenbin Li, Lucy Yong, and Feng Dong. 731 9. Contributors 733 Qiandeng Liang 734 Huawei Technologies 735 101 Software Avenue, Yuhuatai District 736 Nanjing 210012 737 China 739 Email: liangqiandeng@huawei.com 741 Normative References 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, DOI 745 10.17487/RFC2119, March 1997, . 748 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 749 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 750 10.17487/RFC4271, January 2006, . 753 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 754 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 755 RFC 4761, DOI 10.17487/RFC4761, January 2007, 756 . 758 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 759 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 760 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 761 . 763 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 764 "Provisioning, Auto-Discovery, and Signaling in Layer 2 765 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 766 10.17487/RFC6074, January 2011, . 769 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 770 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 771 2017, . 773 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 774 Bacher, "Dissemination of Flow Specification Rules", RFC 775 8955, DOI 10.17487/RFC8955, December 2020, 776 . 778 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 779 "Dissemination of Flow Specification Rules for IPv6", RFC 780 8956, DOI 10.17487/RFC8956, December 2020, 781 . 783 [RFC9117] Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. 784 Mohapatra, "Revised Validation Procedure for BGP Flow 785 Specifications", RFC 9117, DOI 10.17487/RFC9117, August 786 2021, . 788 Informative References 790 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 791 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 792 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 793 2015, . 795 [RFC7042bis] Eastlake, D., and J. Abley, "IANA Considerations and 796 IETF Protocol and Documentation Usage for IEEE 802 797 Parameters", draft-eastlake-rfc7042bis, work in progress, 798 March 2021. 800 Authors' Addresses 802 Weiguo Hao 803 Huawei Technologies 804 101 Software Avenue, 805 Nanjing 210012 806 China 808 Email: haoweiguo@huawei.com 810 Donald E. Eastlake, 3rd 811 Futurewei Technologies 812 2386 Panoramic Circle 813 Apopka, FL 32703 814 USA 816 Tel: +1-508-333-2270 817 Email: d3e3e3@gmail.com 819 Stephane Litkowski 820 Cisco Systems, Inc. 822 Email: slitkows.ietf@gmail.com 824 Shunwan Zhuang 825 Huawei Technologies 826 Huawei Bld., No.156 Beiqing Rd. 827 Beijing 100095 828 China 830 Email: zhuangshunwan@huawei.com 832 Copyright, Disclaimer, and Additional IPR Provisions 834 Copyright (c) 2022 IETF Trust and the persons identified as the 835 document authors. All rights reserved. 837 This document is subject to BCP 78 and the IETF Trust's Legal 838 Provisions Relating to IETF Documents 839 (http://trustee.ietf.org/license-info) in effect on the date of 840 publication of this document. Please review these documents 841 carefully, as they describe your rights and restrictions with respect 842 to this document. Code Components extracted from this document must 843 include Revised BSD License text as described in Section 4.e of the 844 Trust Legal Provisions and are provided without warranty as described 845 in the Revised BSD License.