idnits 2.17.1 draft-ietf-idr-flowspec-l2vpn-17.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 (May 12, 2021) is 1079 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 709, but not defined == Missing Reference: '0x080B' is mentioned on line 710, 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: November 11, 2021 May 12, 2021 11 BGP Dissemination of L2 Flow Specification Rules 12 draft-ietf-idr-flowspec-l2vpn-17 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 an extended community also are 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 specification rules and 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 give the length, in octets, of the information after the 260 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 5-octet 334 quantities. op is encoded as specified in Section 4.2.1.1 of 335 [RFC8955]. The match fails if EtherType L2 header encoding is being 336 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 using for virtual local-area network (VLAN) stacking or Q-in- 371 Q use. 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] using 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. 434 2.2 Order of Traffic Filtering Rules 436 The existing rules in Section 5.1 of [RFC8955] and in [RFC8956] for 437 the ordering of traffic filtering are extended as follows: 439 L2 flowspecs (AFI = 6, 25) take precedence over L3 flowspecs (AFI = 440 1, 2). Between two L2 flowspecs, precedence of the L2 portion is 441 determined as specified in this section after this paragraph. If the 442 L2 flowspec L2 portions are the same and the L3-AFI is nonzero, then 443 the L3 portions are compared as specified in [RFC8955] or [RFC8956] 444 as appropriate. Note: if the L3-AFI fields are different between two 445 L2 flowspecs, they will never match the same packet so it will not be 446 necessary to prioritize two flowspecs with different L3-AFI values. 448 The original definition for the order of traffic filtering rules can 449 be reused for L2 with new consideration for the MAC Address offset. 450 As long as the offsets are equal, the comparison is the same, 451 retaining longest-prefix-match semantics. If the offsets are not 452 equal, the lowest offset has precedence, as this flow matches the 453 most significant bit. 455 Pseudocode: 456 flow_rule_L2_cmp (a, b) 457 { 458 comp1 = next_component(a); 459 comp2 = next_component(b); 460 while (comp1 || comp2) { 461 // component_type returns infinity on end-of-list 462 if (component_type(comp1) < component_type(comp2)) { 463 return A_HAS_PRECEDENCE; 464 } 465 if (component_type(comp1) > component_type(comp2)) { 466 return B_HAS_PRECEDENCE; 467 } 469 if (component_type(comp1) == MAC_DESTINATION || MAC_SOURCE) { 470 common = MIN(MAC Address length (comp1), 471 MAC Address length (comp2)); 472 cmp = MAC Address compare(comp1, comp2, common); 473 // not equal, lowest value has precedence 474 // equal, longest match has precedence 475 } else { 476 common = 477 MIN(component_length(comp1), component_length(comp2)); 478 cmp = memcmp(data(comp1), data(comp2), common); 479 // not equal, lowest value has precedence 480 // equal, longest string has precedence 481 } 482 } 483 return EQUAL; 484 } 486 3. L2VPN Flow Specification Encoding in BGP 488 The NLRI format for AFI=25/SAFI=134 (L2VPN), as with the other VPN 489 flowspec AFI/SAFI pairs, is the same as the non-VPN Flow-Spec but 490 with the addition of a Route Distinguisher to identify the VPN to 491 which the flowspec is to be applied. 493 In addition, the IANA entry for SAFI 134 is slightly generalized as 494 specified at the beginning of Section 6. 496 The L2VPN NLRI format is as follows: 498 +-------------------------------+ 499 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 500 +-------------------------------+ 501 | Route Distinguisher | 8 octets 502 +-------------------------------+ 503 | L3-AFI | 2 octets 504 +-------------------------------+ 505 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 506 +-------------------------------+ 507 | NLRI-value | variable 508 +-------------------------------+ 510 Figure 2: Flow Specification NLRI for L2VPN 512 The fields in Figure 2, other than the Route Distinguisher, are 513 encoded as specified in Section 2 except that the minimum value for 514 total-length is 12. 516 Flow specification rules received via this NLRI apply only to traffic 517 that belongs to the VPN instance(s) into which it is imported. Flow 518 rules are accepted as specified in Section 5. 520 3.1 Order of L2VPN Filtering Rules 522 The order between L2VPN filtering rules is determined as specified in 523 Section 2.2. Note that if the Route Distinguisher is different 524 between two L2VPN filtering rules, they will never both match the 525 same packet so they need not be prioritized. 527 4. Ethernet Flow Specification Traffic Actions 529 The default action for an L2 traffic filtering flowspec is to accept 530 traffic that matches that particular rule. The following extended 531 community values per [RFC8955] can be used to specify particular 532 actions in an L2 VPN network: 534 +--------+--------------------+----------------------------+ 535 | type | extended community | encoding | 536 +--------+--------------------+----------------------------+ 537 | 0x8006 | traffic-rate | 2-octet as#, 4-octet float | 538 | 0x8007 | traffic-action | bitmask | 539 | 0x8008 | redirect | 6-octet Route Target | 540 | 0x8009 | traffic-marking | DSCP value | 541 +--------+--------------------+----------------------------+ 543 Redirect: The action should be redefined to allow the traffic to be 544 redirected to a MAC or IP VRF routing instance that lists the 545 specified route-target in its import policy. 547 Besides the above extended communities, this document also specifies 548 the following BGP extended communities for Ethernet flows to extend 549 [RFC8955]: 551 +--------+------------------------+--------------------------+ 552 | type | extended community | encoding | 553 +--------+------------------------+--------------------------+ 554 | TBD1 | VLAN-action | bitmask | 555 | TBD2 | TPID-action | bitmask | 556 +--------+------------------------+--------------------------+ 558 4.1 VLAN-action 560 The VLAN-action extended community, as shown in the diagram below, 561 consists of 6 octets that include action Flags, two VLAN IDs, and the 562 associated PCP and DEI values. The action Flags fields are further 563 divided into two parts which correspond to the first action and the 564 second action respectively. Bit 0 to bit 7 give the first action 565 while bit 8 to bit 15 give the second action. The bits of PO, PU, 566 SW, RI and RO in each part represent the action of Pop, Push, Swap, 567 Rewrite inner VLAN and Rewrite outer VLAN respectively. Through this 568 method, more complicated actions also can be represented in a single 569 VLAN-action extended community, such as SwapPop, PushSwap, etc. For 570 example, SwapPop action is the sequence of two actions, the first 571 action is Swap and the second action is Pop. 573 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 574 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 575 |PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv | 576 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 577 | VLAN ID1 | PCP1 |DE1| 578 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 579 | VLAN ID2 | PCP2 |DE2| 580 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 582 PO1: Pop action. If the PO1 flag is one, it indicates the outmost 583 VLAN should be removed. 585 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 586 added, the associated PCP and DEI are PCP1 and DE1. 588 SW1: Swap action. If the SW1 flag is one, it indicates the outer 589 VLAN and inner VLAN should be swapped. 591 PO2: Pop action. If the PO2 flag is one, it indicates the outmost 592 VLAN should be removed. 594 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 595 added, the associated PCP and DEI are PCP2 and DE2. 597 SW2: Swap action. If the SW2 flag is one, it indicates the outer 598 VLAN and inner VLAN should be swapped. 600 RI1 and RI2: Rewrite inner VLAN action. If the RIx flag is one 601 (where "x" is "1" or "2"), it indicates the inner VLAN should be 602 replaced by a new VLAN where the new VLAN is VLAN IDx and the 603 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 604 action is to only modify the PCP and DEI value of the inner VLAN. 606 RO1 and RO2: Rewrite outer VLAN action. If the ROx flag is one 607 (where "x" is "1" or "2"), it indicates the outer VLAN should be 608 replaced by a new VLAN where the new VLAN is VLAN IDx and the 609 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 610 action is to only modify the PCP and DEI value of the outer VLAN. 612 Resv: Reserved for future use. MUST be sent as zero and ignored on 613 receipt. 615 Giving an example below: if the action of PUSH Inner VLAN 10 with PCP 616 value 5 and DEI value 0 and PUSH Outer VLAN 20 with PCP value 6 and 617 DEI value 0 is needed, the format of the VLAN-action extended 618 community is as follows: 620 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 621 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 622 |0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 | 623 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 624 | 10 |1 |0 |1 |0 | 625 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 626 | 20 |1 |1 |0 |0 | 627 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 629 4.2 TPID-action 631 The TPID-action extended community consists of 6 octets which 632 includes the fields of action Flags, TP ID1 and TP ID2. 634 0 15 635 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 636 |TI|TO| Resv | 637 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 638 | TP ID1 | 639 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 640 | TP ID2 | 641 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 643 TI: Mapping inner TP ID action. If the TI flag is one, it indicates 644 the inner TP ID should be replaced by a new TP ID, the new TP ID is 645 TP ID1. 647 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 648 the outer TP ID should be replaced by a new TP ID, the new TP ID is 649 TP ID2. 651 Resv: Reserved for future use. MUST be sent as zero and ignored on 652 receipt. 654 5. Flow Spec Validation 656 Flow Specifications received over AFI=25/SAFI=134 are validated 657 against routing reachability received over AFI=25/SAFI=128 as 658 modified to conform to [FlowSpecOID]. 660 6. IANA Considerations 662 IANA is requested to change the description for SAFI 134 [RFC8955] to 663 read as follows and to change the reference for it to [this 664 document]: 666 134 VPN dissemination of flow specification rules 668 IANA is requested to create an L2 Flow Specification Component Type 669 registry on the Flow Spec Component Types registries web page as 670 follows: 672 Name: L2 Flow Specification Component Types 673 Reference: [this document] 674 Registration Procedures: 675 0 Reserved 676 1-127 Specification Required 677 128-255 First Come First Served 679 Initial contents: 680 +------+-----------------------+------------------------------+ 681 | type | Reference | description | 682 +------+-----------------------+------------------------------+ 683 | 0 | [this document] | Reserved | 684 | 1 | [this document] | Ethernet Type | 685 | 2 | [this document] | Source MAC | 686 | 3 | [this document] | Destination MAC | 687 | 4 | [this document] | DSAP in LLC | 688 | 5 | [this document] | SSAP in LLC | 689 | 6 | [this document] | Control field in LLC | 690 | 7 | [this document] | SNAP | 691 | 8 | [this document] | VLAN ID | 692 | 9 | [this document] | VLAN PCP | 693 | 10 | [this document] | Inner VLAN ID | 694 | 11 | [this document] | Inner VLAN PCP | 695 | 12 | [this document] | VLAN DEI | 696 | 13 | [this document] | Inner VLAN DEI | 697 | 14 | [this document] | Source MAC Special Bits | 698 | 15 | [this document] | Destination MAC Special Bits| 699 |16-254| [this document] | unassigned | 700 | 255 | [this document] | Reserved | 701 +------+-----------------------+------------------------------+ 703 IANA is requested to assign two values from the "BGP Extended 704 Communities Type - extended, transitive" registry [suggested value 705 provided in square brackets]: 707 Type value Name Reference 708 ------------ ------------------------ --------------- 709 TBD1[0x080A] Flow spec VLAN action [this document] 710 TBD2[0x080B] Flow spec TPID action [this document] 712 7. Security Considerations 714 For General BGP Flow Specification Security Considerations, see 715 [RFC8955]. 717 VLAN tagging identifies Layer 2 communities which are commonly 718 expected to be isolated except when higher layer connection is 719 provided, such as Layer 3 routing. Thus, the ability of the flowspec 720 VLAN action to change the VLAN ID in a frame might compromise 721 security. 723 8. Acknowledgements 725 The authors wish to acknowledge the important contributions and 726 suggestions of the following: 728 Hannes Gredler, Xiaohu Xu, Zhenbin Li, Lucy Yong, and Feng Dong. 730 9. Contributors 732 Qiandeng Liang 733 Huawei Technologies 734 101 Software Avenue, Yuhuatai District 735 Nanjing 210012 736 China 738 Email: liangqiandeng@huawei.com 740 Normative References 742 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 743 Requirement Levels", BCP 14, RFC 2119, DOI 744 10.17487/RFC2119, March 1997, . 747 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 748 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 749 10.17487/RFC4271, January 2006, . 752 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 753 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 754 RFC 4761, DOI 10.17487/RFC4761, January 2007, 755 . 757 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 758 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 759 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 760 . 762 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 763 "Provisioning, Auto-Discovery, and Signaling in Layer 2 764 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 765 10.17487/RFC6074, January 2011, . 768 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 769 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 770 2017, . 772 [RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. 773 Bacher, "Dissemination of Flow Specification Rules", RFC 774 8955, DOI 10.17487/RFC8955, December 2020, 775 . 777 [RFC8956] Loibl, C., Ed., Raszuk, R., Ed., and S. Hares, Ed., 778 "Dissemination of Flow Specification Rules for IPv6", RFC 779 8956, DOI 10.17487/RFC8956, December 2020, 780 . 782 [FlowSpecOID] Uttaro, J., Alcaide, J., Filsfils, C. Smith, D., 783 Mohapatra, P., draft-ietf-idr-bgp-flowspec-oid, work in 784 progress, April 2021. 786 Informative References 788 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 789 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 790 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 791 2015, . 793 [RFC7042bis] Eastlake, D., and J. Abley, "IANA Considerations and 794 IETF Protocol and Documentation Usage for IEEE 802 795 Parameters", draft-eastlake-rfc7042bis, work in progress, 796 March 2021. 798 Authors' Addresses 800 Weiguo Hao 801 Huawei Technologies 802 101 Software Avenue, 803 Nanjing 210012 804 China 806 Email: haoweiguo@huawei.com 808 Donald E. Eastlake, 3rd 809 Futurewei Technologies 810 2386 Panoramic Circle 811 Apopka, FL 32703 812 USA 814 Tel: +1-508-333-2270 815 Email: d3e3e3@gmail.com 817 Stephane Litkowski 818 Cisco Systems, Inc. 820 Email: slitkows.ietf@gmail.com 822 Shunwan Zhuang 823 Huawei Technologies 824 Huawei Bld., No.156 Beiqing Rd. 825 Beijing 100095 826 China 828 Email: zhuangshunwan@huawei.com 830 Copyright, Disclaimer, and Additional IPR Provisions 832 Copyright (c) 2021 IETF Trust and the persons identified as the 833 document authors. All rights reserved. 835 This document is subject to BCP 78 and the IETF Trust's Legal 836 Provisions Relating to IETF Documents 837 (http://trustee.ietf.org/license-info) in effect on the date of 838 publication of this document. Please review these documents 839 carefully, as they describe your rights and restrictions with respect 840 to this document. Code Components extracted from this document must 841 include Simplified BSD License text as described in Section 4.e of 842 the Trust Legal Provisions and are provided without warranty as 843 described in the Simplified BSD License.