idnits 2.17.1 draft-ietf-idr-flowspec-l2vpn-14.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 12, 2020) is 1474 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 713, but not defined == Missing Reference: '0x080B' is mentioned on line 714, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-10 Summary: 0 errors (**), 0 flaws (~~), 5 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 J. Uttaro 6 AT&T 7 S. Litkowski 8 Cisco Systems 9 S. Zhuang 10 Huawei Technologies 11 Expires: October 11, 2020 April 12, 2020 13 BGP Dissemination of L2 Flow Specification Rules 14 draft-ietf-idr-flowspec-l2vpn-14 16 Abstract 17 This document defines a Border Gateway Protocol (BGP) Flow 18 Specification (flowspec) extension to disseminate Ethernet Layer 2 19 (L2) and Layer 2 Virtual Private Network (L2VPN) traffic filtering 20 rules either by themselves or in conjunction with L3 flowspecs. 21 AFI/SAFI 6/133 and 25/134 are used for these purposes. New component 22 types and an extended community also are defined. 24 Status of This Document 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Distribution of this document is unlimited. Comments should be sent 30 to the authors or the IDR Working Group mailing list . 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 44 Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Table of Contents 49 1. Introduction............................................3 50 1.1 Terminology............................................4 52 2. Layer 2 Flow Specification Encoding.....................5 53 2.1 L2 Component Types.....................................6 54 2.1.1 Type 1 - Ethernet Type (EtherType)...................6 55 2.1.2 Type 2 - Source MAC..................................7 56 2.1.3 Type 3 - Destination MAC.............................7 57 2.1.4 Type 4 - DSAP (Destination Service Access Point).....7 58 2.1.5 Type 5 - SSAP (Source Service Access Point)..........7 59 2.1.6 Type 6 - Control field in LLC........................8 60 2.1.7 Type 7 - SNAP........................................8 61 2.1.8 Type 8 - VLAN ID.....................................8 62 2.1.9 Type 9 - VLAN PCP....................................8 63 2.1.10 Type 10 - Inner VLAN ID.............................9 64 2.1.11 Type 11 - Inner VLAN PCP............................9 65 2.1.12 Type 12 - VLAN DEI..................................9 66 2.1.13 Type 13 - Inner VLAN DEI...........................10 67 2.1.14 Type 14 - Source MAC Special Bits..................10 68 2.1.15 Type 15 - Destination MAC Special Bits.............10 69 2.2 Order of Traffic Filtering Rules......................10 71 3. L2VPN Flow Specification Encoding in BGP...............12 72 3.1 Order of L2VPN Filtering Rules........................12 74 4. Ethernet Flow Specification Traffic Actions............13 75 4.1 VLAN-action...........................................13 76 4.2 TPID-action...........................................15 78 5. Flow Spec Validation...................................16 80 6. IANA Considerations....................................17 81 7. Security Considerations................................19 83 8. Acknowledgements.......................................19 84 9. Contributors...........................................19 86 Normative References......................................20 87 Informative References....................................21 89 Authors' Addresses........................................22 91 1. Introduction 93 Border Gateway Protocol (BGP) Flow Specification [RFC5575bis] 94 (flowspec) is an extension to BGP that supports the dissemination of 95 traffic flow specification rules and actions to be taken on packets 96 in a specified flow. It leverages the BGP Control Plane to simplify 97 the distribution of ACLs (Access Control Lists). Using the Flow 98 Specification extension new filter rules can be injected to all BGP 99 peers simultaneously without changing router configuration. A 100 typical application is to automate the distribution of traffic filter 101 lists to routers for DDoS (Distributed Denial of Service) mitigation, 102 access control, and similar applications. 104 BGP Flow Specification [RFC5575bis] defines a BGP Network Layer 105 Reachability Information (NLRI) format used to distribute traffic 106 flow specification rules. The NLRI for (AFI=1, SAFI=133) specifies 107 IPv4 unicast filtering. The NLRI for (AFI=1, SAFI=134) specifies 108 IPv4 BGP/MPLS VPN filtering [RFC7432]. The Flow Specification match 109 part defined in [RFC5575bis] only includes L3/L4 information like 110 IPv4 source/destination prefix, protocol, ports, and the like, so 111 traffic flows can only be filtered based on L3/L4 information. This 112 has been extended by [FlowSpecV6] to cover IPv6 (AFI=2) L3/L4. 114 Layer 2 Virtual Private Networks (L2VPNs) have been deployed in an 115 increasing number of networks. Such networks also have requirements 116 to deploy BGP Flow Specification to mitigate DDoS attack traffic. 117 Within an L2VPN network, both IP and non-IP Ethernet traffic may 118 exist. For IP traffic filtering, the VPN Flow Specification rules 119 defined in [RFC5575bis] and/or [FlowSpecV6], which include match 120 criteria and actions, can still be used. For non-IP Ethernet traffic 121 filtering, Layer 2 related information like source/destination MAC 122 and VLAN must be considered. 124 There are different kinds of L2VPN networks like EVPN [RFC7432], BGP 125 VPLS [RFC4761], LDP VPLS [RFC4762] and border gateway protocol (BGP) 126 auto discovery [RFC6074]. Because the Flow Specification feature 127 relies on the BGP protocol to distribute traffic filtering rules, it 128 can only be incrementally deployed in those L2VPN networks where BGP 129 has already been used for auto discovery and/or signaling purposes 130 such as BGP-based VPLS [RFC4761], EVPN, and LDP-based VPLS [RFC4762] 131 with BGP auto-discovery [RFC6074]. 133 This document defines new flowspec component types and two new 134 extended communities to support L2 and L2VPN flowspec applications. 135 The flowspec rules can be enforced on all border routers or on some 136 interface sets of the border routers. SAFI=133 in [RFC5575bis] and 137 [FlowSpecV6] is extended for AFI=6 as specified in Section 2 to cover 138 L2 traffic filtering information and in Section 3 SAFI=134 is 139 extended for AFI=25 to cover the L2VPN environment. 141 1.1 Terminology 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here. 149 The following acronyms and terms are used in this document: 151 AFI - Address Family Identifier 153 ACL - Access Control List 155 DDoS - Distributed Denial of Service 157 DEI - Drop Eligible Indicator 159 EVPN - Ethernet VPN [RFC7432] 161 flowspec - BGP Flow Specification 163 L2 - Layer 2 165 L2VPN - Layer 2 VPN 167 L3 - Layer 3 169 L3VPN - Layer 3 VPN 171 NLRI - Network Layer Reachability Information 173 PCP - Priority Code Point [802.1Q] 175 SAFI - Subsequent Address Family Identifier 177 TPID - Tag Protocol ID, typically a VLAN ID 179 VLAN - Virtual Local Area Network 181 VPLS - Virtual Private Line Service [RFC4762] 183 VPN - Virtual Private Network 185 2. Layer 2 Flow Specification Encoding 187 [RFC5575bis] defines SAFI 133 and SAFI 134, with AFI=1, for 188 "dissemination of IPv4 flow specification rules" and "dissemination 189 of VPNv4 flow specification rules", respectively. [FlowSpecV6]] 190 extends [RFC5575bis] to also allow AFI=2 thus making it applicable to 191 both IPv4 and IPv6 applications. This document further extends 192 SAFI=133 for AFI=6 and SAFI=134 for AFI=25 to make them applicable to 193 L2 and L2VPN applications. This document also provides for the 194 optional combination of L3 flow specifications with these L2 flow 195 specifications. 197 This section specifies the L2 flowspec for AFI=6/SAFI=133. To 198 simplify assignments, a new registry is used for L2 flowspec. Since 199 it is frequently desirable to also filter on L3/L4 fields, provision 200 is made for their inclusion along with an indication of the L3 201 protocol involved (IPv4 or IPv6). 203 The NLRI part of the MP_REACH_NLRI and MP_UNREACH_NLRI is encoded as 204 a 1- or 2-octet total NLRI length field followed by several fields as 205 described below. 207 +-------------------------------+ 208 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 209 +-------------------------------+ 210 | L3-AFI | 2 octets 211 +-------------------------------+ 212 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 213 +-------------------------------+ 214 | NLRI-value | variable 215 +-------------------------------+ 217 Figure 1: Flow Specification NLRI for L2 219 The fields show in Figure 1 are further specified below: 221 total-length: The length of the subsequent fields (L3 AFI, 222 L2-length, and NRLI-value) encoded as provided in Section 4.1 223 of [RFC5575bis]. If this field is less than 4, which is the 224 minimum valid value, then the NLRI is malformed in which case a 225 NOTIFICATION message is sent and the BGP connection closed as 226 provided in Section 6.3 of [RFC4271]. 228 L3-AFI: If no L3/L4 filtering is desired, this two octet field 229 MUST be zero which is a reserved AFI value. Otherwise L3-AFI 230 indicates the L3 protocol involved by giving its AFI (0x0001 231 for IPv4 or 0x0002 for IPv6). If the receiver does not 232 understand the value of the L3-AFI field, the MP_REACH or 233 MP_UNREACH attribute is ignored. 235 L2-length: The length of the L2 components at the beginning of the 236 NLRI-value field encoded as provided in Section 4.1 of 237 [RFC5575bis]. If the value of this field indicates that the L2 238 components extend beyond the total-length, the NLRI is 239 malformed in which case a NOTIFICATION message is sent and the 240 BGP connection closed as provided in Section 6.3 of [RFC4271]. 241 N2-length MAY be zero although, in that case, it would have 242 been more efficient to encode the attribute as an L3 Flow spec 243 unless it is desired to apply an L2 action (see Section 4). A 244 null L2 flowspec always matches. 246 NLRI-value: This consists of the L2 flowspec, of length L2-length, 247 followed by an optionally present L3 flowspec. The result can 248 be treated in most ways as a single flowspec, matching the 249 intersection (AND) of all the components except that the 250 components in the initial L2 region are interpreted as L2 251 components and the remainder as L3 components per the L3-AFI 252 field. This is necessary because there are different registries 253 for the L2, L3 IPv4, and L3 IPv6 component types. If the L3 254 flowspec is null (length zero), it always matches. 256 2.1 L2 Component Types 258 The L2 flowspec portion of the NLRI-value consists of flowspec 259 components as in [RFC5575bis] but using L2 components and types as 260 specified below. All components start with a type octet followed by a 261 length octet followed by any additional information needed. The 262 length octet give the length, in octets, of the information after the 263 length octet. This structure applies to all new components to be 264 defined in the L2 Flow-spec Component Registry (see Section 6) and to 265 all existing components except Types 2 and 3 where the length is in 266 bits. 268 2.1.1 Type 1 - Ethernet Type (EtherType) 270 Encoding: 272 Defines a list of {operation, value} pairs used to match the two- 273 octet EtherType field. op is encoded as specified in Section 4.2.1.1 274 of [RFC5575bis]. Values are encoded as 2-octet quantities. Ethernet 275 II framing defines the two-octet Ethernet Type (EtherType) field in 276 an Ethernet frame, preceded by destination and source MAC addresses, 277 that identifies an upper layer protocol encapsulating the frame data. 278 The match fails if LLC encoding is being used rather than EtherType 279 encoding. 281 2.1.2 Type 2 - Source MAC 283 Encoding: 285 Defines the source MAC Address prefix to match encoded as in BGP 286 UPDATE messages [RFC4271]. Prefix length is in bits and the MAC 287 Prefix is fill out with from 1 to 7 padding bits so that it is an 288 integer number of octets. These padding bits are ignored for matching 289 purposes. 291 2.1.3 Type 3 - Destination MAC 293 Encoding: 295 Defines the destination MAC Address to match encoded as in BGP UPDATE 296 messages [RFC4271]. Prefix length is in bits and the MAC Prefix is 297 fill out with from 1 to 7 padding bits so that it is an integer 298 number of octets. These padding bits are ignored for matching 299 purposes. 301 2.1.4 Type 4 - DSAP (Destination Service Access Point) 303 Encoding: 305 Defines a list of {operation, value} pairs used to match the 1-octet 306 DSAP in the IEEE 802.2 LLC (Logical Link Control Header). Values are 307 encoded as 1-octet quantities. op is encoded as specified in Section 308 4.2.1.1 of [RFC5575bis]. The match fails if EtherType L2 header 309 encoding is being used rather than LLC encoding. 311 2.1.5 Type 5 - SSAP (Source Service Access Point) 313 Encoding: 315 Defines a list of {operation, value} pairs used to match the 1-octet 316 SSAP in the IEEE 802.2 LLC. Values are encoded as 1-octet 317 quantities. op is encoded as specified in Section 4.2.1.1 of 318 [RFC5575bis]. The match fails if EtherType L2 header encoding is 319 being used rather than LLC encoding. 321 2.1.6 Type 6 - Control field in LLC 323 Encoding: 325 Defines a list of {operation, value} pairs used to match the 1-octet 326 control field in the IEEE 802.2 LLC. Values are encoded as 1-octet 327 quantities. op is encoded as specified in Section 4.2.1.1 of 328 [RFC5575bis]. The match fails if EtherType L2 header encoding is 329 being used rather than LLC encoding. 331 2.1.7 Type 7 - SNAP 333 Encoding: 335 Defines a list of {operation, value} pairs used to match 5-octet SNAP 336 (Sub-Network Access Protocol) field. Values are encoded as 5-octet 337 quantities. op is encoded as specified in Section 4.2.1.1 of 338 [RFC5575bis]. The match fails if EtherType L2 header encoding is 339 being used rather than LLC encoding. 341 2.1.8 Type 8 - VLAN ID 343 Encoding: 345 Defines a list of {operation, value} pairs used to match VLAN ID. 346 Values are encoded as 2-octet quantities, where the four most 347 significant bits are set to zero and ignored for matching and the 12 348 least significant bits contain the VLAN value. op is encoded as 349 specified in Section 4.2.1.1 of [RFC5575bis]. 351 In the virtual local-area network (VLAN) stacking case, the VLAN ID 352 is the outer VLAN ID. 354 2.1.9 Type 9 - VLAN PCP 356 Encoding: 358 Defines a list of {operation, value} pairs used to match 3-bit VLAN 359 PCP (priority code point) fields [802.1Q]. Values are encoded using 360 a single octet, where the five most significant bits are set to zero 361 and ignored for matching and the three least significant bits contain 362 the VLAN PCP value. op is encoded as specified in Section 4.2.1.1 of 363 [RFC5575bis]. 365 In the virtual local-area network (VLAN) stacking case, the VLAN PCP 366 is part of the outer VLAN tag. 368 2.1.10 Type 10 - Inner VLAN ID 370 Encoding: 372 Defines a list of {operation, value} pairs used to match the inner 373 VLAN ID using for virtual local-area network (VLAN) stacking or Q-in- 374 Q use. Values are encoded as 2-octet quantities, where the four most 375 significant bits are set to zero and ignored for matching and the 12 376 least significant bits contain the VLAN value. op is encoded as 377 specified in Section 4.2.1.1 of [RFC5575bis]. 379 In the single VLAN case, this component type MUST NOT be used. If it 380 appears the match will fail. 382 2.1.11 Type 11 - Inner VLAN PCP 384 Encoding: 386 Defines a list of {operation, value} pairs used to match 3-bit inner 387 VLAN PCP fields [802.1Q] using for virtual local-area network (VLAN) 388 stacking or Q in Q use. Values are encoded using a single octet, 389 where the five most significant bits are set to zero and ignored for 390 matching and the three least significant bits contain the VLAN PCP 391 value. op is encoded as specified in Section 4.2.1.1 of [RFC5575bis]. 393 In the single VLAN case, this component type MUST NOT be used. If it 394 appears the match will fail. 396 2.1.12 Type 12 - VLAN DEI 398 Encoding: 400 This type tests the DEI (Drop Eligible Indicator) bit in the VLAN 401 tag. If op is zero, it matches if and only if the DEI bit is zero. If 402 op is non-zero, it matches if and only if the DEI bit is one. 404 In the virtual local-area network (VLAN) stacking case, the VLAN DEI 405 is part of the outer VLAN tag. 407 2.1.13 Type 13 - Inner VLAN DEI 409 Encoding: 411 This type tests the DEI bit in the inner VLAN tag. If op is zero, it 412 matches if and only if the DEI bit is zero. If op is non-zero, it 413 matches if and only if the DEI bit is one. 415 In the single VLAN case, this component type MUST NOT be used. If it 416 appears the match will fail. 418 2.1.14 Type 14 - Source MAC Special Bits 420 Encoding: 422 This type tests the bottom nibble of the top octet of the Source MAC 423 address. The two low order bits of that nibble have long been the 424 local bit (0x2) and the group addressed bit (0x1). However, recent 425 changes in IEEE 802 have divided the local address space into 4 426 quadrants specified by the next two bits (0x4 and 0x8) [RFC7042bis]. 427 This flowspec component permits testing, for example, that a MAC is 428 group addressed or is a local address in a particular quadrant. The 429 encoding is as given in Section 4.2.1.2 of [RFC5575bis]. 431 2.1.15 Type 15 - Destination MAC Special Bits 433 Encoding: 435 As discussed in Section 2.1.14 but for the Destination MAC Address. 437 2.2 Order of Traffic Filtering Rules 439 The existing rules in Section 5.1 of [RFC5575bis] and in [FlowSpecV6] 440 for the ordering of traffic filtering are extended as follows: 442 L2 flowspecs (AFI = 6, 25) take precedence over L3 flowspecs (AFI = 443 1, 2). Between two L2 flowspecs, precedence of the L2 portion is 444 determined as specified in this section after this paragraph. If the 445 L2 flowspec L2 portions are the same and the L3-AFI is nonzero, then 446 the L3 portions are compared as specified in [RFC5575bis] or 447 [FlowSpecV6] as appropriate. Note: if the L3-AFI fields are different 448 between two L2 flowspecs, they will never match the same packet so it 449 will not be necessary to prioritize two flowspecs with different 450 L3-AFI values. 452 The original definition for the order of traffic filtering rules can 453 be reused for L2 with new consideration for the MAC Address offset. 454 As long as the offsets are equal, the comparison is the same, 455 retaining longest-prefix-match semantics. If the offsets are not 456 equal, the lowest offset has precedence, as this flow matches the 457 most significant bit. 459 Pseudocode: 460 flow_rule_L2_cmp (a, b) 461 { 462 comp1 = next_component(a); 463 comp2 = next_component(b); 464 while (comp1 || comp2) { 465 // component_type returns infinity on end-of-list 466 if (component_type(comp1) < component_type(comp2)) { 467 return A_HAS_PRECEDENCE; 468 } 469 if (component_type(comp1) > component_type(comp2)) { 470 return B_HAS_PRECEDENCE; 471 } 473 if (component_type(comp1) == MAC_DESTINATION || MAC_SOURCE) { 474 common = MIN(MAC Address length (comp1), 475 MAC Address length (comp2)); 476 cmp = MAC Address compare(comp1, comp2, common); 477 // not equal, lowest value has precedence 478 // equal, longest match has precedence 479 } else { 480 common = 481 MIN(component_length(comp1), component_length(comp2)); 482 cmp = memcmp(data(comp1), data(comp2), common); 483 // not equal, lowest value has precedence 484 // equal, longest string has precedence 485 } 486 } 487 return EQUAL; 488 } 490 3. L2VPN Flow Specification Encoding in BGP 492 The NLRI format for AFI=25/SAFI=134 (L2VPN), as with the other VPN 493 flowspec AFI/SAFI pairs, is the same as the non-VPN Flow-Spec but 494 with the addition of a Route Distinguisher to identify the VPN to 495 which the flowspec is to be applied. 497 In addition, the IANA entry for SAFI 134 is slightly generalized as 498 specified at the beginning of Section 6. 500 The L2VPN NLRI format is as follows: 502 +-------------------------------+ 503 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 504 +-------------------------------+ 505 | Route Distinguisher | 8 octets 506 +-------------------------------+ 507 | L3-AFI | 2 octets 508 +-------------------------------+ 509 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 510 +-------------------------------+ 511 | NLRI-value | variable 512 +-------------------------------+ 514 Figure 2: Flow Specification NLRI for L2VPN 516 The fields in Figure 2, other than the Route Distinguisher, are 517 encoded as specified in Section 2 except that the minimum value for 518 total-length is 12. 520 Flow specification rules received via this NLRI apply only to traffic 521 that belongs to the VPN instance(s) into which it is imported. Flow 522 rules are accepted as specified in Section 5. 524 3.1 Order of L2VPN Filtering Rules 526 The order between L2VPN filtering rules is determined as specified in 527 Section 2.2. Note that if the Route Distinguisher is different 528 between two L2VPN filtering rules, they will never both match the 529 same packet so they need not be prioritized. 531 4. Ethernet Flow Specification Traffic Actions 533 The default action for an L2 traffic filtering flowspec is to accept 534 traffic that matches that particular rule. The following extended 535 community values per [RFC5575bis] can be used to specify particular 536 actions in an L2 VPN network: 538 +--------+--------------------+----------------------------+ 539 | type | extended community | encoding | 540 +--------+--------------------+----------------------------+ 541 | 0x8006 | traffic-rate | 2-octet as#, 4-octet float | 542 | 0x8007 | traffic-action | bitmask | 543 | 0x8008 | redirect | 6-octet Route Target | 544 | 0x8009 | traffic-marking | DSCP value | 545 +--------+--------------------+----------------------------+ 547 Redirect: The action should be redefined to allow the traffic to be 548 redirected to a MAC or IP VRF routing instance that lists the 549 specified route-target in its import policy. 551 Besides the above extended communities, this document also specifies 552 the following BGP extended communities for Ethernet flows to extend 553 [RFC5575bis]: 555 +--------+------------------------+--------------------------+ 556 | type | extended community | encoding | 557 +--------+------------------------+--------------------------+ 558 | TBD1 | VLAN-action | bitmask | 559 | TBD2 | TPID-action | bitmask | 560 +--------+------------------------+--------------------------+ 562 4.1 VLAN-action 564 The VLAN-action extended community, as shown in the diagram below, 565 consists of 6 octets that include action Flags, two VLAN IDs, and the 566 associated PCP and DEI values. The action Flags fields are further 567 divided into two parts which correspond to the first action and the 568 second action respectively. Bit 0 to bit 7 give the first action 569 while bit 8 to bit 15 give the second action. The bits of PO, PU, 570 SW, RI and RO in each part represent the action of Pop, Push, Swap, 571 Rewrite inner VLAN and Rewrite outer VLAN respectively. Through this 572 method, more complicated actions also can be represented in a single 573 VLAN-action extended community, such as SwapPop, PushSwap, etc. For 574 example, SwapPop action is the sequence of two actions, the first 575 action is Swap and the second action is Pop. 577 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 578 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 579 |PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv | 580 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 581 | VLAN ID1 | PCP1 |DE1| 582 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 583 | VLAN ID2 | PCP2 |DE2| 584 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 586 PO1: Pop action. If the PO1 flag is one, it indicates the outmost 587 VLAN should be removed. 589 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 590 added, the associated PCP and DEI are PCP1 and DE1. 592 SW1: Swap action. If the SW1 flag is one, it indicates the outer 593 VLAN and inner VLAN should be swapped. 595 PO2: Pop action. If the PO2 flag is one, it indicates the outmost 596 VLAN should be removed. 598 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 599 added, the associated PCP and DEI are PCP2 and DE2. 601 SW2: Swap action. If the SW2 flag is one, it indicates the outer 602 VLAN and inner VLAN should be swapped. 604 RI1 and RI2: Rewrite inner VLAN action. If the RIx flag is one 605 (where "x" is "1" or "2"), it indicates the inner VLAN should be 606 replaced by a new VLAN where the new VLAN is VLAN IDx and the 607 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 608 action is to only modify the PCP and DEI value of the inner VLAN. 610 RO1 and RO2: Rewrite outer VLAN action. If the ROx flag is one 611 (where "x" is "1" or "2"), it indicates the outer VLAN should be 612 replaced by a new VLAN where the new VLAN is VLAN IDx and the 613 associated PCP and DEI are PCPx and DEx. If the VLAN IDx is 0, the 614 action is to only modify the PCP and DEI value of the outer VLAN. 616 Resv: Reserved for future use. MUST be sent as zero and ignored on 617 receipt. 619 Giving an example below: if the action of PUSH Inner VLAN 10 with PCP 620 value 5 and DEI value 0 and PUSH Outer VLAN 20 with PCP value 6 and 621 DEI value 0 is needed, the format of the VLAN-action extended 622 community is as follows: 624 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 625 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 626 |0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 | 627 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 628 | 10 |1 |0 |1 |0 | 629 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 630 | 20 |1 |1 |0 |0 | 631 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 633 4.2 TPID-action 635 The TPID-action extended community consists of 6 octets which 636 includes the fields of action Flags, TP ID1 and TP ID2. 638 0 15 639 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 640 |TI|TO| Resv | 641 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 642 | TP ID1 | 643 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 644 | TP ID2 | 645 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 647 TI: Mapping inner TP ID action. If the TI flag is one, it indicates 648 the inner TP ID should be replaced by a new TP ID, the new TP ID is 649 TP ID1. 651 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 652 the outer TP ID should be replaced by a new TP ID, the new TP ID is 653 TP ID2. 655 Resv: Reserved for future use. MUST be sent as zero and ignored on 656 receipt. 658 5. Flow Spec Validation 660 Flow Specifications received over AFI=25/SAFI=134 are validated 661 against routing reachability received over AFI=25/SAFI=128 as 662 modified to conform to [FlowSpecOID]. 664 6. IANA Considerations 666 IANA is requested to change the description for SAFI 134 [RFC5575bis] 667 to read as follows and to change the reference for it to [this 668 document]: 670 134 VPN dissemination of flow specification rules 672 IANA is requested to create an L2 Flow Specification Component Type 673 registry on the Flow Spec Component Types registries web page as 674 follows: 676 Name: L2 Flow Specification Component Types 677 Reference: [this document] 678 Registration Procedures: 679 0 Reserved 680 1-127 Specification Required 681 128-255 First Come First Served 683 Initial contents: 684 +------+-----------------------+------------------------------+ 685 | type | Reference | description | 686 +------+-----------------------+------------------------------+ 687 | 0 | [this document] | Reserved | 688 | 1 | [this document] | Ethernet Type | 689 | 2 | [this document] | Source MAC | 690 | 3 | [this document] | Destination MAC | 691 | 4 | [this document] | DSAP in LLC | 692 | 5 | [this document] | SSAP in LLC | 693 | 6 | [this document] | Control field in LLC | 694 | 7 | [this document] | SNAP | 695 | 8 | [this document] | VLAN ID | 696 | 9 | [this document] | VLAN PCP | 697 | 10 | [this document] | Inner VLAN ID | 698 | 11 | [this document] | Inner VLAN PCP | 699 | 12 | [this document] | VLAN DEI | 700 | 13 | [this document] | Inner VLAN DEI | 701 | 14 | [this document] | Source MAC Special Bits | 702 | 15 | [this document] | Destination MAC Special Bits| 703 |16-254| [this document] | unassigned | 704 | 255 | [this document] | Reserved | 705 +------+-----------------------+------------------------------+ 707 IANA is requested to assign two values from the "BGP Extended 708 Communities Type - extended, transitive" registry [suggested value 709 provided in square brackets]: 711 Type value Name Reference 712 ------------ ------------------------ --------------- 713 TBD1[0x080A] Flow spec VLAN action [this document] 714 TBD2[0x080B] Flow spec TPID action [this document] 716 7. Security Considerations 718 For General BGP Flow Specification Security Considerations, see 719 [RFC5575bis]. 721 VLAN tagging identifies Layer 2 communities which are commonly 722 expected to be isolated except when higher layer connection is 723 provided, such as Layer 3 routing. Thus, the ability of the flowspec 724 VLAN action to change the VLAN ID in a frame might compromise 725 security. 727 8. Acknowledgements 729 The authors wish to acknowledge the important contributions and 730 suggestions of the following: 732 Hannes Gredler, Xiaohu Xu, Zhenbin Li, Lucy Yong, and Feng Dong. 734 9. Contributors 736 Qiandeng Liang 737 Huawei Technologies 738 101 Software Avenue, Yuhuatai District 739 Nanjing 210012 740 China 742 Email: liangqiandeng@huawei.com 744 Normative References 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, DOI 748 10.17487/RFC2119, March 1997, . 751 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 752 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 753 10.17487/RFC4271, January 2006, . 756 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 757 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 758 RFC 4761, DOI 10.17487/RFC4761, January 2007, 759 . 761 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 762 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 763 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 764 . 766 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 767 "Provisioning, Auto-Discovery, and Signaling in Layer 2 768 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 769 10.17487/RFC6074, January 2011, . 772 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 773 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 774 2017, . 776 [FlowSpecOID] Uttaro, J., Alcaide, J., Filsfils, C. Smith, D., 777 Mohapatra, P., draft-ietf-idr-bgp-flowspec-oid, work in 778 progress. 780 [FlowSpecV6] McPherson, D., Raszuk, R., Pithawala, B., 781 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 782 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 783 v6-10. Work in progress. 785 [RFC5575bis] Hares, S., Loibl, C., Raszuk, R., McPherson, D., Bacher, 786 M., "Dissemination of Flow Specification Rules", draft- 787 ietf-idr-rfc5575bis, Work in progress. 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. 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 James Uttaro 820 AT&T 822 Email: uttaro@att.com 824 Stephane Litkowski 825 Cisco Systems, Inc. 827 Email: slitkows.ietf@gmail.com 829 Shunwan Zhuang 830 Huawei Technologies 831 Huawei Bld., No.156 Beiqing Rd. 832 Beijing 100095 833 China 835 Email: zhuangshunwan@huawei.com 837 Copyright, Disclaimer, and Additional IPR Provisions 839 Copyright (c) 2020 IETF Trust and the persons identified as the 840 document authors. All rights reserved. 842 This document is subject to BCP 78 and the IETF Trust's Legal 843 Provisions Relating to IETF Documents 844 (http://trustee.ietf.org/license-info) in effect on the date of 845 publication of this document. Please review these documents 846 carefully, as they describe your rights and restrictions with respect 847 to this document. Code Components extracted from this document must 848 include Simplified BSD License text as described in Section 4.e of 849 the Trust Legal Provisions and are provided without warranty as 850 described in the Simplified BSD License.