idnits 2.17.1 draft-ietf-idr-flowspec-l2vpn-18.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 (October 23, 2021) is 914 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 711, but not defined == Missing Reference: '0x080B' is mentioned on line 712, 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: April 22, 2022 October 23, 2021 11 BGP Dissemination of L2 Flow Specification Rules 12 draft-ietf-idr-flowspec-l2vpn-18 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 81 8. Acknowledgements.......................................19 82 9. Contributors...........................................19 84 Normative References......................................20 85 Informative References....................................21 87 Authors' Addresses........................................22 89 1. Introduction 91 Border Gateway Protocol (BGP) Flow Specification [RFC8955] (flowspec) 92 is an extension to BGP that supports the dissemination of traffic 93 flow specifications and resulting actions to be taken on packets in a 94 specified flow. It leverages the BGP Control Plane to simplify the 95 distribution of ACLs (Access Control Lists). Using the Flow 96 Specification extension new filter rules can be injected to all BGP 97 peers simultaneously without changing router configuration. A 98 typical application is to automate the distribution of traffic filter 99 lists to routers for DDoS (Distributed Denial of Service) mitigation, 100 access control, and similar applications. 102 BGP Flow Specification [RFC8955] defines a BGP Network Layer 103 Reachability Information (NLRI) format used to distribute traffic 104 flow specification rules. The NLRI for (AFI=1, SAFI=133) specifies 105 IPv4 unicast filtering. The NLRI for (AFI=1, SAFI=134) specifies 106 IPv4 BGP/MPLS VPN filtering [RFC7432]. The Flow Specification match 107 part defined in [RFC8955] only includes L3/L4 information like IPv4 108 source/destination prefix, protocol, ports, and the like, so traffic 109 flows can only be filtered based on L3/L4 information. This has been 110 extended by [RFC8956] to cover IPv6 (AFI=2) L3/L4. 112 Layer 2 Virtual Private Networks (L2VPNs) have been deployed in an 113 increasing number of networks. Such networks also have requirements 114 to deploy BGP Flow Specification to mitigate DDoS attack traffic. 115 Within an L2VPN network, both IP and non-IP Ethernet traffic may 116 exist. For IP traffic filtering, the VPN Flow Specification rules 117 defined in [RFC8955] and/or [RFC8956], which include match criteria 118 and actions, can still be used. For non-IP Ethernet traffic 119 filtering, Layer 2 related information like source/destination MAC 120 and VLAN must be considered. 122 There are different kinds of L2VPN networks like EVPN [RFC7432], BGP 123 VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP) 124 auto discovery [RFC6074]. Because the Flow Specification feature 125 relies on the BGP protocol to distribute traffic filtering rules, it 126 can only be incrementally deployed in those L2VPN networks where BGP 127 has already been used for auto discovery and/or signaling purposes 128 such as BGP-based VPLS [RFC4761], EVPN, and LDP-based VPLS [RFC4762] 129 with BGP auto-discovery [RFC6074]. 131 This document defines new flowspec component types and two new 132 extended communities to support L2 and L2VPN flowspec applications. 133 The flowspec rules can be enforced on all border routers or on some 134 interface sets of the border routers. SAFI=133 in [RFC8955] and 135 [RFC8956] is extended for AFI=6 as specified in Section 2 to cover L2 136 traffic filtering information and in Section 3 SAFI=134 is extended 137 for AFI=25 to cover the L2VPN environment. 139 1.1 Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 The following acronyms and terms are used in this document: 149 AFI - Address Family Identifier 151 ACL - Access Control List 153 DDoS - Distributed Denial of Service 155 DEI - Drop Eligible Indicator 157 EVPN - Ethernet VPN [RFC7432] 159 flowspec - BGP Flow Specification 161 L2 - Layer 2 163 L2VPN - Layer 2 VPN 165 L3 - Layer 3 167 L3VPN - Layer 3 VPN 169 NLRI - Network Layer Reachability Information 171 PCP - Priority Code Point [802.1Q] 173 SAFI - Subsequent Address Family Identifier 175 TPID - Tag Protocol ID, typically a VLAN ID 177 VLAN - Virtual Local Area Network 179 VPLS - Virtual Private Line Service [RFC4762] 181 VPN - Virtual Private Network 183 2. Layer 2 Flow Specification Encoding 185 [RFC8955] defines SAFI 133 and SAFI 134, with AFI=1, for 186 "dissemination of IPv4 flow specification rules" and "dissemination 187 of VPNv4 flow specification rules", respectively. [RFC8956]] extends 188 [RFC8955] to also allow AFI=2 thus making it applicable to both IPv4 189 and IPv6 applications. This document further extends SAFI=133 for 190 AFI=6 and SAFI=134 for AFI=25 to make them applicable to L2 and L2VPN 191 applications. This document also provides for the optional 192 combination of L3 flow specifications with these L2 flow 193 specifications. 195 This section specifies the L2 flowspec for AFI=6/SAFI=133. To 196 simplify assignments, a new registry is used for L2 flowspec. Since 197 it is frequently desirable to also filter on L3/L4 fields, provision 198 is made for their inclusion along with an indication of the L3 199 protocol involved (IPv4 or IPv6). 201 The NLRI part of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 202 a 1- or 2-octet total NLRI length field followed by several fields as 203 described below. 205 +-------------------------------+ 206 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 207 +-------------------------------+ 208 | L3-AFI | 2 octets 209 +-------------------------------+ 210 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 211 +-------------------------------+ 212 | NLRI-value | variable 213 +-------------------------------+ 215 Figure 1: Flow Specification NLRI for L2 217 The fields show in Figure 1 are further specified below: 219 total-length: The length of the subsequent fields (L3 AFI, 220 L2-length, and NRLI-value) encoded as provided in Section 4.1 221 of [RFC8955]. If this field is less than 4, which is the 222 minimum valid value, then the NLRI is malformed in which case a 223 NOTIFICATION message is sent and the BGP connection closed as 224 provided in Section 6.3 of [RFC4271]. 226 L3-AFI: If no L3/L4 filtering is desired, this two octet field 227 MUST be zero which is a reserved AFI value. Otherwise L3-AFI 228 indicates the L3 protocol involved by giving its AFI (0x0001 229 for IPv4 or 0x0002 for IPv6). If the receiver does not 230 understand the value of the L3-AFI field, the MP_REACH or 231 MP_UNREACH attribute is ignored. 233 L2-length: The length of the L2 components at the beginning of the 234 NLRI-value field encoded as provided in Section 4.1 of 235 [RFC8955]. If the value of this field indicates that the L2 236 components extend beyond the total-length, the NLRI is 237 malformed in which case a NOTIFICATION message is sent and the 238 BGP connection closed as provided in Section 6.3 of [RFC4271]. 239 N2-length MAY be zero although, in that case, it would have 240 been more efficient to encode the attribute as an L3 Flow spec 241 unless it is desired to apply an L2 action (see Section 4). A 242 null L2 flowspec always matches. 244 NLRI-value: This consists of the L2 flowspec, of length L2-length, 245 followed by an optionally present L3 flowspec. The result can 246 be treated in most ways as a single flowspec, matching the 247 intersection (AND) of all the components except that the 248 components in the initial L2 region are interpreted as L2 249 components and the remainder as L3 components per the L3-AFI 250 field. This is necessary because there are different registries 251 for the L2, L3 IPv4, and L3 IPv6 component types. If the L3 252 flowspec is null (length zero), it always matches. 254 2.1 L2 Component Types 256 The L2 flowspec portion of the NLRI-value consists of flowspec 257 components as in [RFC8955] but using L2 components and types as 258 specified below. All components start with a type octet followed by a 259 length octet followed by any additional information needed. The 260 length octet gives the length, in octets, of the information after 261 the length octet. This structure applies to all new components to be 262 defined in the L2 Flow-spec Component Registry (see Section 6) and to 263 all existing components except Types 2 and 3 where the length is in 264 bits. 266 2.1.1 Type 1 - Ethernet Type (EtherType) 268 Encoding: 270 Defines a list of {operation, value} pairs used to match the two- 271 octet EtherType field. op is encoded as specified in Section 4.2.1.1 272 of [RFC8955]. Values are encoded as 2-octet quantities. Ethernet II 273 framing defines the two-octet Ethernet Type (EtherType) field in an 274 Ethernet frame, preceded by destination and source MAC addresses, 275 that identifies an upper layer protocol encapsulating the frame data. 276 The match fails if LLC encoding is being used rather than EtherType 277 encoding. 279 2.1.2 Type 2 - Source MAC 281 Encoding: 283 Defines the source MAC Address prefix to match encoded as in BGP 284 UPDATE messages [RFC4271]. Prefix length is in bits and the MAC 285 Prefix is fill out with from 1 to 7 padding bits so that it is an 286 integer number of octets. These padding bits are ignored for matching 287 purposes. 289 2.1.3 Type 3 - Destination MAC 291 Encoding: 293 Defines the destination MAC Address to match encoded as in BGP UPDATE 294 messages [RFC4271]. Prefix length is in bits and the MAC Prefix is 295 fill out with from 1 to 7 padding bits so that it is an integer 296 number of octets. These padding bits are ignored for matching 297 purposes. 299 2.1.4 Type 4 - DSAP (Destination Service Access Point) 301 Encoding: 303 Defines a list of {operation, value} pairs used to match the 1-octet 304 DSAP in the IEEE 802.2 LLC (Logical Link Control Header). Values are 305 encoded as 1-octet quantities. op is encoded as specified in Section 306 4.2.1.1 of [RFC8955]. The match fails if EtherType L2 header encoding 307 is being used rather than LLC encoding. 309 2.1.5 Type 5 - SSAP (Source Service Access Point) 311 Encoding: 313 Defines a list of {operation, value} pairs used to match the 1-octet 314 SSAP in the IEEE 802.2 LLC. Values are encoded as 1-octet 315 quantities. op is encoded as specified in Section 4.2.1.1 of 316 [RFC8955]. The match fails if EtherType L2 header encoding is being 317 used rather than LLC encoding. 319 2.1.6 Type 6 - Control field in LLC 321 Encoding: 323 Defines a list of {operation, value} pairs used to match the 1-octet 324 control field in the IEEE 802.2 LLC. Values are encoded as 1-octet 325 quantities. op is encoded as specified in Section 4.2.1.1 of 326 [RFC8955]. The match fails if EtherType L2 header encoding is being 327 used rather than LLC encoding. 329 2.1.7 Type 7 - SNAP 331 Encoding: 333 Defines a list of {operation, value} pairs used to match 5-octet SNAP 334 (Sub-Network Access Protocol) field. Values are encoded as 8-octet 335 quantities with the zero padded SNAP left justified. op is encoded as 336 specified in Section 4.2.1.1 of [RFC8955]. The match fails if 337 EtherType L2 header encoding is being used rather than LLC encoding. 339 2.1.8 Type 8 - VLAN ID 341 Encoding: 343 Defines a list of {operation, value} pairs used to match VLAN ID. 344 Values are encoded as 2-octet quantities, where the four most 345 significant bits are set to zero and ignored for matching and the 12 346 least significant bits contain the VLAN value. op is encoded as 347 specified in Section 4.2.1.1 of [RFC8955]. 349 In the virtual local-area network (VLAN) stacking case, the VLAN ID 350 is the outer VLAN ID. 352 2.1.9 Type 9 - VLAN PCP 354 Encoding: 356 Defines a list of {operation, value} pairs used to match 3-bit VLAN 357 PCP (priority code point) fields [802.1Q]. Values are encoded using 358 a single octet, where the five most significant bits are set to zero 359 and ignored for matching and the three least significant bits contain 360 the VLAN PCP value. op is encoded as specified in Section 4.2.1.1 of 361 [RFC8955]. 363 In the virtual local-area network (VLAN) stacking case, the VLAN PCP 364 is part of the outer VLAN tag. 366 2.1.10 Type 10 - Inner VLAN ID 368 Encoding: 370 Defines a list of {operation, value} pairs used to match the inner 371 VLAN ID for virtual local-area network (VLAN) stacking or Q-in-Q use. 372 Values are encoded as 2-octet quantities, where the four most 373 significant bits are set to zero and ignored for matching and the 12 374 least significant bits contain the VLAN value. op is encoded as 375 specified in Section 4.2.1.1 of [RFC8955]. 377 In the single VLAN case, this component type MUST NOT be used. If it 378 appears the match will fail. 380 2.1.11 Type 11 - Inner VLAN PCP 382 Encoding: 384 Defines a list of {operation, value} pairs used to match 3-bit inner 385 VLAN PCP fields [802.1Q] for virtual local-area network (VLAN) 386 stacking or Q-in-Q use. Values are encoded using a single octet, 387 where the five most significant bits are set to zero and ignored for 388 matching and the three least significant bits contain the VLAN PCP 389 value. op is encoded as specified in Section 4.2.1.1 of [RFC8955]. 391 In the single VLAN case, this component type MUST NOT be used. If it 392 appears the match will fail. 394 2.1.12 Type 12 - VLAN DEI 396 Encoding: 398 This type tests the DEI (Drop Eligible Indicator) bit in the VLAN 399 tag. If op is zero, it matches if and only if the DEI bit is zero. If 400 op is non-zero, it matches if and only if the DEI bit is one. 402 In the virtual local-area network (VLAN) stacking case, the VLAN DEI 403 is part of the outer VLAN tag. 405 2.1.13 Type 13 - Inner VLAN DEI 407 Encoding: 409 This type tests the DEI bit in the inner VLAN tag. If op is zero, it 410 matches if and only if the DEI bit is zero. If op is non-zero, it 411 matches if and only if the DEI bit is one. 413 In the single VLAN case, this component type MUST NOT be used. If it 414 appears the match will fail. 416 2.1.14 Type 14 - Source MAC Special Bits 418 Encoding: 420 This type tests the bottom nibble of the top octet of the Source MAC 421 address. The two low order bits of that nibble have long been the 422 local bit (0x2) and the group addressed bit (0x1). However, recent 423 changes in IEEE 802 have divided the local address space into 4 424 quadrants specified by the next two bits (0x4 and 0x8) [RFC7042bis]. 425 This flowspec component permits testing, for example, that a MAC is 426 group addressed or is a local address in a particular quadrant. The 427 encoding is as given in Section 4.2.1.2 of [RFC8955]. 429 2.1.15 Type 15 - Destination MAC Special Bits 431 Encoding: 433 As discussed in Section 2.1.14 but for the Destination MAC Address 434 special bits. 436 2.2 Order of Traffic Filtering Rules 438 The existing rules in Section 5.1 of [RFC8955] and in [RFC8956] for 439 the ordering of traffic filtering are extended as follows: 441 L2 flowspecs (AFI = 6, 25) take precedence over L3 flowspecs (AFI = 442 1, 2). Between two L2 flowspecs, precedence of the L2 portion is 443 determined as specified in this section after this paragraph. If the 444 L2 flowspec L2 portions are the same and the L3-AFI is nonzero, then 445 the L3 portions are compared as specified in [RFC8955] or [RFC8956] 446 as appropriate. Note: if the L3-AFI fields are different between two 447 L2 flowspecs, they will never match the same packet so it will not be 448 necessary to prioritize two flowspecs with different L3-AFI values. 450 The original definition for the order of traffic filtering rules can 451 be reused for L2 with new consideration for the MAC Address offset. 452 As long as the offsets are equal, the comparison is the same, 453 retaining longest-prefix-match semantics. If the offsets are not 454 equal, the lowest offset has precedence, as this flow matches the 455 most significant bit. 457 Pseudocode: 458 flow_rule_L2_cmp (a, b) 459 { 460 comp1 = next_component(a); 461 comp2 = next_component(b); 462 while (comp1 || comp2) { 463 // component_type returns infinity on end-of-list 464 if (component_type(comp1) < component_type(comp2)) { 465 return A_HAS_PRECEDENCE; 466 } 467 if (component_type(comp1) > component_type(comp2)) { 468 return B_HAS_PRECEDENCE; 469 } 471 if (component_type(comp1) == MAC_DESTINATION || MAC_SOURCE) { 472 common = MIN(MAC Address length (comp1), 473 MAC Address length (comp2)); 474 cmp = MAC Address compare(comp1, comp2, common); 475 // not equal, lowest value has precedence 476 // equal, longest match has precedence 477 } else { 478 common = 479 MIN(component_length(comp1), component_length(comp2)); 480 cmp = memcmp(data(comp1), data(comp2), common); 481 // not equal, lowest value has precedence 482 // equal, longest string has precedence 483 } 484 } 485 return EQUAL; 486 } 488 3. L2VPN Flow Specification Encoding in BGP 490 The NLRI format for AFI=25/SAFI=134 (L2VPN), as with the other VPN 491 flowspec AFI/SAFI pairs, is the same as the non-VPN Flow-Spec but 492 with the addition of a Route Distinguisher to identify the VPN to 493 which the flowspec is to be applied. 495 In addition, the IANA entry for SAFI 134 is slightly generalized as 496 specified at the beginning of Section 6. 498 The L2VPN NLRI format is as follows: 500 +-------------------------------+ 501 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 502 +-------------------------------+ 503 | Route Distinguisher | 8 octets 504 +-------------------------------+ 505 | L3-AFI | 2 octets 506 +-------------------------------+ 507 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 508 +-------------------------------+ 509 | NLRI-value | variable 510 +-------------------------------+ 512 Figure 2: Flow Specification NLRI for L2VPN 514 The fields in Figure 2, other than the Route Distinguisher, are 515 encoded as specified in Section 2 except that the minimum value for 516 total-length is 12. 518 Flow specification rules received via this NLRI apply only to traffic 519 that belongs to the VPN instance(s) into which it is imported. Flow 520 rules are accepted as specified in Section 5. 522 3.1 Order of L2VPN Filtering Rules 524 The order between L2VPN filtering rules is determined as specified in 525 Section 2.2. Note that if the Route Distinguisher is different 526 between two L2VPN filtering rules, they will never both match the 527 same packet so they need not be prioritized. 529 4. Ethernet Flow Specification Traffic Actions 531 The default action for an L2 traffic filtering flowspec is to accept 532 traffic that matches that particular rule. The following extended 533 community values per [RFC8955] can be used to specify particular 534 actions in an L2 VPN network: 536 +--------+--------------------+----------------------------+ 537 | type | extended community | encoding | 538 +--------+--------------------+----------------------------+ 539 | 0x8006 | traffic-rate | 2-octet as#, 4-octet float | 540 | 0x8007 | traffic-action | bitmask | 541 | 0x8008 | redirect | 6-octet Route Target | 542 | 0x8009 | traffic-marking | DSCP value | 543 +--------+--------------------+----------------------------+ 545 Redirect: The action should be redefined to allow the traffic to be 546 redirected to a MAC or IP VRF routing instance that lists the 547 specified route-target in its import policy. 549 Besides the above extended communities, this document also specifies 550 the following BGP extended communities for Ethernet flows to extend 551 [RFC8955]: 553 +--------+------------------------+--------------------------+ 554 | type | extended community | encoding | 555 +--------+------------------------+--------------------------+ 556 | TBD1 | VLAN-action | bitmask | 557 | TBD2 | TPID-action | bitmask | 558 +--------+------------------------+--------------------------+ 560 4.1 VLAN-action 562 The VLAN-action extended community, as shown in the diagram below, 563 consists of 6 octets that include action Flags, two VLAN IDs, and the 564 associated PCP and DEI values. The action Flags fields are further 565 divided into two parts which correspond to the first action and the 566 second action respectively. Bit 0 to bit 7 give the first action 567 while bit 8 to bit 15 give the second action. The bits of PO, PU, 568 SW, RI and RO in each part represent the action of Pop, Push, Swap, 569 Rewrite inner VLAN and Rewrite outer VLAN respectively. Through this 570 method, more complicated actions also can be represented in a single 571 VLAN-action extended community, such as SwapPop, PushSwap, etc. For 572 example, SwapPop action is the sequence of two actions, the first 573 action is Swap and the second action is Pop. 575 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 576 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 577 |PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv | 578 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 579 | VLAN ID1 | PCP1 |DE1| 580 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 581 | VLAN ID2 | PCP2 |DE2| 582 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 584 PO1: Pop action. If the PO1 flag is one, it indicates the outmost 585 VLAN should be removed. 587 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 588 added, the associated PCP and DEI are PCP1 and DE1. 590 SW1: Swap action. If the SW1 flag is one, it indicates the outer 591 VLAN and inner VLAN should be swapped. 593 PO2: Pop action. If the PO2 flag is one, it indicates the outmost 594 VLAN should be removed. 596 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 597 added, the associated PCP and DEI are PCP2 and DE2. 599 SW2: Swap action. If the SW2 flag is one, it indicates the outer 600 VLAN and inner VLAN should be swapped. 602 RI1 and RI2: Rewrite inner VLAN action. If the RIx flag is one 603 (where "x" is "1" or "2"), it indicates the inner VLAN should be 604 replaced by a new VLAN where the new VLAN is VLAN IDx and the 605 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 606 action is to only modify the PCP and DEI value of the inner VLAN. 608 RO1 and RO2: Rewrite outer VLAN action. If the ROx flag is one 609 (where "x" is "1" or "2"), it indicates the outer VLAN should be 610 replaced by a new VLAN where the new VLAN is VLAN IDx and the 611 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 612 action is to only modify the PCP and DEI value of the outer VLAN. 614 Resv: Reserved for future use. MUST be sent as zero and ignored on 615 receipt. 617 Giving an example below: if the action of PUSH Inner VLAN 10 with PCP 618 value 5 and DEI value 0 and PUSH Outer VLAN 20 with PCP value 6 and 619 DEI value 0 is needed, the format of the VLAN-action extended 620 community is as follows: 622 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 623 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 624 |0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 | 625 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 626 | 10 |1 |0 |1 |0 | 627 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 628 | 20 |1 |1 |0 |0 | 629 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 631 4.2 TPID-action 633 The TPID-action extended community consists of 6 octets which 634 includes the fields of action Flags, TP ID1 and TP ID2. 636 0 15 637 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 638 |TI|TO| Resv | 639 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 640 | TP ID1 | 641 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 642 | TP ID2 | 643 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 645 TI: Mapping inner TP ID action. If the TI flag is one, it indicates 646 the inner TP ID should be replaced by a new TP ID, the new TP ID is 647 TP ID1. 649 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 650 the outer TP ID should be replaced by a new TP ID, the new TP ID is 651 TP ID2. 653 Resv: Reserved for future use. MUST be sent as zero and ignored on 654 receipt. 656 5. Flow Spec Validation 658 Flow Specifications received over AFI=25/SAFI=134 are validated 659 against routing reachability received over AFI=25/SAFI=128 as 660 modified to conform to [RFC9117]. 662 6. IANA Considerations 664 IANA is requested to change the description for SAFI 134 [RFC8955] to 665 read as follows and to change the reference for it to [this 666 document]: 668 134 VPN dissemination of flow specification rules 670 IANA is requested to create an L2 Flow Specification Component Type 671 registry on the Flow Spec Component Types registries web page as 672 follows: 674 Name: L2 Flow Specification Component Types 675 Reference: [this document] 676 Registration Procedures: 677 0 Reserved 678 1-127 Specification Required 679 128-255 First Come First Served 681 Initial contents: 682 +------+-----------------------+------------------------------+ 683 | type | Reference | description | 684 +------+-----------------------+------------------------------+ 685 | 0 | [this document] | Reserved | 686 | 1 | [this document] | Ethernet Type | 687 | 2 | [this document] | Source MAC | 688 | 3 | [this document] | Destination MAC | 689 | 4 | [this document] | DSAP in LLC | 690 | 5 | [this document] | SSAP in LLC | 691 | 6 | [this document] | Control field in LLC | 692 | 7 | [this document] | SNAP | 693 | 8 | [this document] | VLAN ID | 694 | 9 | [this document] | VLAN PCP | 695 | 10 | [this document] | Inner VLAN ID | 696 | 11 | [this document] | Inner VLAN PCP | 697 | 12 | [this document] | VLAN DEI | 698 | 13 | [this document] | Inner VLAN DEI | 699 | 14 | [this document] | Source MAC Special Bits | 700 | 15 | [this document] | Destination MAC Special Bits| 701 |16-254| [this document] | unassigned | 702 | 255 | [this document] | Reserved | 703 +------+-----------------------+------------------------------+ 705 IANA is requested to assign two values from the "BGP Extended 706 Communities Type - extended, transitive" registry [suggested value 707 provided in square brackets]: 709 Type value Name Reference 710 ------------ ------------------------ --------------- 711 TBD1[0x080A] Flow spec VLAN action [this document] 712 TBD2[0x080B] Flow spec TPID action [this document] 714 7. Security Considerations 716 For General BGP Flow Specification Security Considerations, see 717 [RFC8955]. 719 VLAN tagging identifies Layer 2 communities which are commonly 720 expected to be isolated except when higher layer connection is 721 provided, such as Layer 3 routing. Thus, the ability of the flowspec 722 VLAN action to change the VLAN ID in a frame might compromise 723 security. 725 8. Acknowledgements 727 The authors wish to acknowledge the important contributions and 728 suggestions of the following: 730 Hannes Gredler, Xiaohu Xu, Zhenbin Li, Lucy Yong, and Feng Dong. 732 9. Contributors 734 Qiandeng Liang 735 Huawei Technologies 736 101 Software Avenue, Yuhuatai District 737 Nanjing 210012 738 China 740 Email: liangqiandeng@huawei.com 742 Normative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, DOI 746 10.17487/RFC2119, March 1997, . 749 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 750 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 751 10.17487/RFC4271, January 2006, . 754 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 755 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 756 RFC 4761, DOI 10.17487/RFC4761, January 2007, 757 . 759 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 760 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 761 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 762 . 764 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 765 "Provisioning, Auto-Discovery, and Signaling in Layer 2 766 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 767 10.17487/RFC6074, January 2011, . 770 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 771 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 772 2017, . 774 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 775 Bacher, "Dissemination of Flow Specification Rules", RFC 776 8955, DOI 10.17487/RFC8955, December 2020, 777 . 779 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 780 "Dissemination of Flow Specification Rules for IPv6", RFC 781 8956, DOI 10.17487/RFC8956, December 2020, 782 . 784 [RFC9117] Uttaro, J., Alcaide, J., Filsfils, C., Smith, D., and P. 785 Mohapatra, "Revised Validation Procedure for BGP Flow 786 Specifications", RFC 9117, DOI 10.17487/RFC9117, August 787 2021, . 789 Informative References 791 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 792 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 793 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 794 2015, . 796 [RFC7042bis] Eastlake, D., and J. Abley, "IANA Considerations and 797 IETF Protocol and Documentation Usage for IEEE 802 798 Parameters", draft-eastlake-rfc7042bis, work in progress, 799 March 2021. 801 Authors' Addresses 803 Weiguo Hao 804 Huawei Technologies 805 101 Software Avenue, 806 Nanjing 210012 807 China 809 Email: haoweiguo@huawei.com 811 Donald E. Eastlake, 3rd 812 Futurewei Technologies 813 2386 Panoramic Circle 814 Apopka, FL 32703 815 USA 817 Tel: +1-508-333-2270 818 Email: d3e3e3@gmail.com 820 Stephane Litkowski 821 Cisco Systems, Inc. 823 Email: slitkows.ietf@gmail.com 825 Shunwan Zhuang 826 Huawei Technologies 827 Huawei Bld., No.156 Beiqing Rd. 828 Beijing 100095 829 China 831 Email: zhuangshunwan@huawei.com 833 Copyright, Disclaimer, and Additional IPR Provisions 835 Copyright (c) 2021 IETF Trust and the persons identified as the 836 document authors. All rights reserved. 838 This document is subject to BCP 78 and the IETF Trust's Legal 839 Provisions Relating to IETF Documents 840 (http://trustee.ietf.org/license-info) in effect on the date of 841 publication of this document. Please review these documents 842 carefully, as they describe your rights and restrictions with respect 843 to this document. Code Components extracted from this document must 844 include Simplified BSD License text as described in Section 4.e of 845 the Trust Legal Provisions and are provided without warranty as 846 described in the Simplified BSD License.