idnits 2.17.1 draft-ietf-idr-flowspec-l2vpn-13.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 (December 31, 2019) is 1549 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 691, but not defined == Missing Reference: '0x080B' is mentioned on line 692, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-10 == Outdated reference: A later version (-27) exists of draft-ietf-idr-rfc5575bis-18 Summary: 0 errors (**), 0 flaws (~~), 6 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: June 30, 2020 December 31, 2019 13 BGP Dissemination of L2 Flow Specification Rules 14 draft-ietf-idr-flowspec-l2vpn-13 16 Abstract 17 This document defines a Border Gateway Protocol (BGP) Flow-spec 18 extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual 19 Private Network (L2VPN) traffic filtering rules either by themselves 20 or in conjunction with L3 Flow-specs. AFI/SAFI 6/133 and 25/134 are 21 used for these purposes. New component types and an extended 22 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........................7 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.............................8 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............................9 67 2.1.14 Type 14 - Source MAC Special Bits...................9 68 2.1.15 Type 15 - Destination MAC Special Bits.............10 69 2.2 Order of L2 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 82 7. Security Considerations................................18 83 8. Acknowledgements.......................................18 84 9. Contributors...........................................18 86 Normative References......................................19 87 Informative References....................................20 89 1. Introduction 91 Border Gateway Protocol (BGP) Flow-spec [RFC5575bis] is an extension 92 to BGP that supports the dissemination of traffic flow specification 93 rules and actions to be taken on packets in a specified flow. It 94 leverages the BGP Control Plane to simplify the distribution of ACLs 95 (Access Control Lists). Using the Flow-spec extension new filter 96 rules can be injected to all BGP peers simultaneously without 97 changing router configuration. A typical application is to automate 98 the distribution of traffic filter lists to routers for DDoS 99 (Distributed Denial of Service) mitigation, access control, and 100 similar applications. 102 BGP Flow-spec [RFC5575bis] defines a BGP Network Layer Reachability 103 Information (NLRI) format used to distribute traffic flow 104 specification rules. NLRI (AFI=1, SAFI=133) is for IPv4 unicast 105 filtering. NLRI (AFI=1, SAFI=134) is for IPv4 BGP/MPLS VPN filtering 106 [RFC7432]. The Flow specification match part defined in [RFC5575bis] 107 only includes L3/L4 information like IPv4 source/destination prefix, 108 protocol, ports, and the like, so traffic flows can only be filtered 109 based on L3/L4 information. This has been extended by [FlowSpecV6] 110 which covers 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-spec to mitigate DDoS attack traffic. Within an 115 L2VPN network, both IP and non-IP Ethernet traffic maybe exist. For 116 IP traffic filtering, the VPN Flow specification rules defined in 117 [RFC5575bis] and/or [FlowSpecV6], which include match criteria and 118 actions, can still be used. Flow specification rules received via the 119 new NLRI format apply only to traffic that belongs to the VPN 120 instance(s) in which it is imported. 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-spec feature relies on 127 the BGP protocol to distribute traffic filtering rules, it can only 128 be incrementally deployed in those L2VPN networks where BGP has 129 already been used for auto discovery and/or signaling purposes such 130 as BGP-based VPLS [RFC4761], EVPN and LDP-based VPLS [RFC4762] with 131 BGP auto-discovery [RFC6074]. 133 This draft defines new Flow-spec component types and two new extended 134 communities to support L2 and L2VPN Flow-spec applications. The 135 Flow-spec 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 are used in this document: 151 AFI - Address Family Identifier 153 ACL - Access Control List 155 DDoS - Distributed Denial of Service 157 EVPN - Ethernet VPN [RFC7432] 159 L2 - Layer 2 161 L2VPN - Layer 2 VPN 163 L3 - Layer 3 165 L3VPN - Layer 3 VPN 167 NLRI - Network Layer Reachability Information 169 PCP - Priority Code Point [802.1Q] 171 SAFI - Subsequent Address Family Identifier 173 TPID - Tag Protocol ID, typically a VLAN ID 175 VLAN - Virtual Local Area Network 177 VPLS - Virtual Private Line Service [RFC4762] 179 VPN - Virtual Private Network 181 2. Layer 2 Flow Specification Encoding 183 [RFC5575bis] defines SAFI 133 and SAFI 134, with AFI=1, for 184 "dissemination of IPv4 flow specification rules" and "dissemination 185 of VPNv4 flow specification rules", respectively. [FlowSpecV6]] 186 extends [RFC5575bis] to also allow AFI=2 thus making it applicable to 187 both IPv4 and IPv6 applications. This document further extends 188 SAFI=133 for AFI=6 and SAFI=134 for AFI=25 to make them applicable to 189 L2 and L2VPN applications. This document also provides for the 190 optional inclusion of L3 flow specifications with the L2 flow 191 specifications. 193 This section specifies the L2 Flow Spec for AFI=6/SAFI=133. (SAFI=133 194 is updated by the [FlowSpecV6] draft so as to not be restricted to 195 the Layer of the AFI with which it operates.) To simplify 196 assignments, a new registry is used for L2 Flow-spec. Since it is 197 frequently desirable to also filter on L3/L4 fields, provision is 198 made for their inclusion along with an indication of the L3 protocol 199 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-vaue) encoded as provided in Section 4.1 of 221 [RFC5575bis]. 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. Otherwise it indicates the L3 protocol involved 228 by giving its AFI (0x0001 for IPv4 or 0x0002 for IPv6). If the 229 receiver does not understand the value of this field, the 230 MP_REACH or 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 [RFC5575bis]. 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 Flow-spec always matches. 243 NLRI-value: This consists of the L2 Flow Spec, of length 244 L2-length, followed by an optionally present L3 Flow. The 245 result can be treated in most ways as a single Flow spec, 246 matching the intersection (AND) of all the components except 247 that the components in the initial L2 region are interpreted as 248 L2 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 Flow-spec is null (length zero), it always matches. 253 2.1 L2 Component Types 255 The L2 Flow-spec portion of NLRI-value consists of Flow-spec 256 components as in [RFC5575bis] 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 [RFC5575bis]. Values are encoded as 2-octet quantities. Ethernet 272 II framing defines the two-octet Ethernet Type (EtherType) field in 273 an Ethernet frame, preceded by destination and source MAC addresses, 274 that identifies an upper layer protocol encapsulating the frame data. 276 2.1.2 Type 2 - Source MAC 278 Encoding: 280 Defines the source MAC Address prefix to match encoded as in BGP 281 UPDATE messages [RFC4271]. Prefix length is in bits and the MAC 282 Prefix is fill out with unused bit to an integer number of octets. 284 2.1.3 Type 3 - Destination MAC 286 Encoding: 288 Defines the destination MAC Address to match encoded as in BGP UPDATE 289 messages [RFC4271]. Prefix length is in bits and the MAC Prefix is 290 fill out with unused bit to an integer number of octets. 292 2.1.4 Type 4 - DSAP (Destination Service Access Point) 294 Encoding: 296 Defines a list of {operation, value} pairs used to match the 1-octet 297 DSAP in the IEEE 802.2 LLC (Logical Link Control Header). Values are 298 encoded as 1-octet quantities. op is encoded as specified in Section 299 4.2.1.1 of [RFC5575bis]. 301 2.1.5 Type 5 - SSAP (Source Service Access Point) 303 Encoding: 305 Defines a list of {operation, value} pairs used to match the 1-octet 306 SSAP in the IEEE 802.2 LLC. Values are encoded as 1-octet 307 quantities. op is encoded as specified in Section 4.2.1.1 of 308 [RFC5575bis]. 310 2.1.6 Type 6 - Control field in LLC 312 Encoding: 314 Defines a list of {operation, value} pairs used to match 1-octet 315 control field in the IEEE 802.2 LLC. Values are encoded as 1-octet 316 quantities. op is encoded as specified in Section 4.2.1.1 of 317 [RFC5575bis]. 319 2.1.7 Type 7 - SNAP 321 Encoding: 323 Defines a list of {operation, value} pairs used to match 5-octet SNAP 324 (Sub-Network Access Protocol) field. Values are encoded as 5-octet 325 quantities. op is encoded as specified in Section 4.2.1.1 of 326 [RFC5575bis]. 328 2.1.8 Type 8 - VLAN ID 330 Encoding: 332 Defines a list of {operation, value} pairs used to match VLAN ID. 333 Values are encoded as 2-octet quantities, where the four most 334 significant bits are zero and the 12 least significant bits contain 335 the VLAN value. op is encoded as specified in Section 4.2.1.1 of 336 [RFC5575bis]. 338 In the virtual local-area network (VLAN) stacking case, the VLAN ID 339 is the outer VLAN ID. 341 2.1.9 Type 9 - VLAN PCP 343 Encoding: 345 Defines a list of {operation, value} pairs used to match 3-bit VLAN 346 PCP fields [802.1Q]. Values are encoded using a single octet, where 347 the five most significant bits are zero and the three least 348 significant bits contain the VLAN PCP 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 PCP 352 is outer VLAN PCP. 354 2.1.10 Type 10 - Inner VLAN ID 356 Encoding: 358 Defines a list of {operation, value} pairs used to match the inner 359 VLAN ID using for virtual local-area network (VLAN) stacking or Q-in- 360 Q use. Values are encoded as 2-octet quantities, where the four most 361 significant bits are zero and the 12 least significant bits contain 362 the VLAN value. op is encoded as specified in Section 4.2.1.1 of 364 [RFC5575bis]. 366 In the single VLAN case, this component type MUST NOT be used. If it 367 appears the match will fail. 369 2.1.11 Type 11 - Inner VLAN PCP 371 Encoding: 373 Defines a list of {operation, value} pairs used to match 3-bit inner 374 VLAN PCP fields [802.1Q] using for virtual local-area network (VLAN) 375 stacking or Q in Q use. Values are encoded using a single octet, 376 where the five most significant bits are zero and the three least 377 significant bits contain the VLAN PCP value. op is encoded as 378 specified in Section 4.2.1.1 of [RFC5575bis]. 380 In the single VLAN case, this component type MUST NOT be used. If it 381 appears the match will fail. 383 2.1.12 Type 12 - VLAN DEI 385 Encoding: 387 This type tests the DEI bit in the VLAN tag. If op is zero, it 388 matches if and only if the DEI bit is zero. If op is non-zero, it 389 matches if and only if the DEI bit is one. 391 2.1.13 Type 13 - Inner VLAN DEI 393 Encoding: 395 This type tests the DEI bit in the inner VLAN tag. If op is zero, it 396 matches if and only if the DEI bit is zero. If op is non-zero, it 397 matches if and only if the DEI bit is one. 399 In the single VLAN case, this component type MUST NOT be used. If it 400 appears the match will fail. 402 2.1.14 Type 14 - Source MAC Special Bits 404 Encoding: 405 This type tests the bottom nibble of the top octet of the Source MAC 406 address. The two low order bits of that nibble have long been the 407 local bit (0x2) and the group addressed bit (0x1). However, recent 408 changes in IEEE 802 have divided the local address space into 4 409 quadrants specified by the next two bits (0x4 and 0x8) [RFC7042bis]. 410 This type permits testing, for example, that a MAC is group addressed 411 or is a local address in a particular quadrant. The encoding is as 412 given in Section 4.2.1.2 of [RFC5575bis]. 414 2.1.15 Type 15 - Destination MAC Special Bits 416 Encoding: 418 As discussed in Section 2.1.14 but for the Destination MAC Address. 420 2.2 Order of L2 Traffic Filtering Rules 422 L2 Flow-specs take precedence over L3 Flow-specs. Between two L2 423 Flow-specs, precedence is determined as specified in this section 424 after this paragraph. If the L2 Flow-specs are the same, then the L3 425 Flow-specs are compared as specified in [RFC5575bis or [FlowSpecV6] 426 as appropriate. Note: if the L3-AFI fields are different between two 427 L2 Flow-specs, they will never match the same packet so it will not 428 be necessary to prioritize two Flow-specs with different L3-AFI 429 values. 431 The original definition for the order of traffic filtering rules can 432 be reused for L2 with new consideration for the MAC Address offset. 433 As long as the offsets are equal, the comparison is the same, 434 retaining longest-prefix-match semantics. If the offsets are not 435 equal, the lowest offset has precedence, as this flow matches the 436 most significant bit. 438 Pseudocode: 439 flow_rule_L2_cmp (a, b) 440 { 441 comp1 = next_component(a); 442 comp2 = next_component(b); 443 while (comp1 || comp2) { 444 // component_type returns infinity on end-of-list 445 if (component_type(comp1) < component_type(comp2)) { 446 return A_HAS_PRECEDENCE; 447 } 448 if (component_type(comp1) > component_type(comp2)) { 449 return B_HAS_PRECEDENCE; 450 } 452 if (component_type(comp1) == MAC_DESTINATION || MAC_SOURCE) { 453 common = MIN(MAC Address length (comp1), 454 MAC Address length (comp2)); 455 cmp = MAC Address compare(comp1, comp2, common); 456 // not equal, lowest value has precedence 457 // equal, longest match has precedence 458 } else { 459 common = 460 MIN(component_length(comp1), component_length(comp2)); 461 cmp = memcmp(data(comp1), data(comp2), common); 462 // not equal, lowest value has precedence 463 // equal, longest string has precedence 464 } 465 } 466 return EQUAL; 467 } 469 3. L2VPN Flow Specification Encoding in BGP 471 The NLRI format for AFI=25/SAFI=134 (L2VPN), as with the other VPN 472 Flow-spec AFI/SAFI pairs, is the same as the non-VPN Flow-Spec but 473 with the addition of a Route Distinguisher to identify the VPN to 474 which the Flow-spec is to be applied. 476 In addition, the IANA entry for SAFI 134 is slightly generalized as 477 specified at the beginning of Section 6. 479 The NLRI format is as follows: 481 +-------------------------------+ 482 | total-length (0xnn or 0xfnnn) | 2 or 3 octets 483 +-------------------------------+ 484 | Route Distinguisher | 8 octets 485 +-------------------------------+ 486 | L3-AFI | 2 octets 487 +-------------------------------+ 488 | L2-length (0xnn or 0xfnnn) | 2 or 3 octets 489 +-------------------------------+ 490 | NLRI-value | variable 491 +-------------------------------+ 493 Figure 2: Flow Specification NLRI for L2VPN 495 The fields in Figure 2, other than the Route Distinguisher, are 496 encoded as specified in Section 2 except that the minimum value for 497 total-length is 12. 499 Flow specification rules received via this NLRI apply only to traffic 500 that belongs to the VPN instance(s) into which it is imported. Flow 501 rules are accepted as specified in Section 5. 503 3.1 Order of L2VPN Filtering Rules 505 The order between L2VPN filtering rules is determined as specified in 506 Section 2.2. Note that if the Route Distinguisher is different 507 between two L2VPN filtering rules, they will never both match the 508 same packet so they need not be prioritized. 510 4. Ethernet Flow Specification Traffic Actions 512 The default action for a layer 2 traffic filtering flow specification 513 is to accept traffic that matches that particular rule. The 514 following extended community values per [RFC5575bis] can be used to 515 specify particular actions in an L2 VPN network: 517 +--------+--------------------+----------------------------+ 518 | type | extended community | encoding | 519 +--------+--------------------+----------------------------+ 520 | 0x8006 | traffic-rate | 2-octet as#, 4-octet float | 521 | 0x8007 | traffic-action | bitmask | 522 | 0x8008 | redirect | 6-octet Route Target | 523 | 0x8009 | traffic-marking | DSCP value | 524 +--------+--------------------+----------------------------+ 526 Redirect: The action should be redefined to allow the traffic to be 527 redirected to a MAC or IP VRF routing instance that lists the 528 specified route-target in its import policy. 530 Besides the above extended communities, this document also specifies 531 the following BGP extended communities for Ethernet flows to extend 532 [RFC5575bis]: 534 +--------+------------------------+--------------------------+ 535 | type | extended community | encoding | 536 +--------+------------------------+--------------------------+ 537 | TBD1 | VLAN-action | bitmask | 538 | TBD2 | TPID-action | bitmask | 539 +--------+------------------------+--------------------------+ 541 4.1 VLAN-action 543 The VLAN-action extended community, as shown in the diagram below, 544 consists of 6 octets that include action Flags, two VLAN IDs, and the 545 associated PCP and DEI values. The action Flags fields are further 546 divided into two parts which correspond to the first action and the 547 second action respectively. Bit 0 to bit 7 give the first action 548 while bit 8 to bit 15 give the second action. The bits of PO, PU, 549 SW, RI and RO in each part represent the action of Pop, Push, Swap, 550 Rewrite inner VLAN and Rewrite outer VLAN respectively. Through this 551 method, more complicated actions also can be represented in a single 552 VLAN-action extended community, such as SwapPop, PushSwap, etc. For 553 example, SwapPop action is the sequence of two actions, the first 554 action is Swap and the second action is Pop. 556 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 557 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 558 |PO1|PU1|SW1|RI1|RO1| Resv |PO2|PU2|SW2|RI2|RO2| Resv | 559 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 560 | VLAN ID1 |PCP1 |DE1| 561 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 562 | VLAN ID2 |PCP2 |DE2| 563 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 565 PO1: Pop action. If the PO1 flag is one, it indicates the outmost 566 VLAN should be removed. 568 PU1: Push action. If PU1 is one, it indicates VLAN ID1 will be 569 added, the associated PCP and DEI are PCP1 and DE1. 571 SW1: Swap action. If the SW1 flag is one, it indicates the outer 572 VLAN and inner VLAN should be swapped. 574 PO2: Pop action. If the PO2 flag is one, it indicates the outmost 575 VLAN should be removed. 577 PU2: Push action. If PU2 is one, it indicates VLAN ID2 will be 578 added, the associated PCP and DEI are PCP2 and DE2. 580 SW2: Swap action. If the SW2 flag is one, it indicates the outer 581 VLAN and inner VLAN should be swapped. 583 RI1 and RI2: Rewrite inner VLAN action. If the RI flag is one, it 584 indicates the inner VLAN should be replaced by a new VLAN where the 585 new VLAN is VLAN ID1 and the associated PCP and DEO are PCP1 and DE1. 586 If the VLAN ID1 is 0, the action is to only modify the PCP and DEI 587 value of the inner VLAN. 589 RO1 and RO2: Rewrite outer VLAN action. If the RO flag is one, it 590 indicates the outer VLAN should be replaced by a new VLAN where the 591 new VLAN is VLAN ID and the associated PCP and DEI are PCP2 and DE2. 592 If the VLAN ID2 is 0, the action is to only modify the PCP and DEI 593 value of the outer VLAN. 595 Resv, R1, and R2: Reserved for future use. MUST be sent as zero and 596 ignored on receipt. 598 Giving an example below: if the action of PUSH Inner VLAN 10 with PCP 599 value 5 DEI value 0 and Outer VLAN 20 with PCP value 6 DEI value 0 is 600 needed, the format of the VLAN-action extended community is as 601 follows: 603 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 604 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 605 |0 |1 |0 |0 |0 |0 |0 |0 |0 |1 |0 |0 |0 |0 |0 |0 | 606 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 607 | 10 |1 |0 |1 |0 | 608 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 609 | 20 |1 |1 |0 |0 | 610 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 612 4.2 TPID-action 614 The TPID-action extended community consists of 6 octets which 615 includes the fields of action Flags, TPID1 and TPID2. 617 0 15 618 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 619 |TI|TO| Resv | 620 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 621 | TP ID1 | 622 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 623 | TP ID2 | 624 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 626 TI: Mapping inner TP ID action. If the TI flag is one, it indicates 627 the inner TP ID should be replaced by a new TP ID, the new TP ID is 628 TP ID1. 630 TO: Mapping outer TP ID action. If the TO flag is one, it indicates 631 the outer TP ID should be replaced by a new TP ID, the new TP ID is 632 TP ID2. 634 Resv: Reserved for future use. MUST be sent as zero and ignored on 635 receipt. 637 5. Flow Spec Validation 639 Flow-specs received over AFI=25/SAFI=134 are validated against 640 routing reachability received over AFI=25/SAFI=128 as modified to 641 conform to [FlowSpecOID]. 643 6. IANA Considerations 645 IANA is requested to change the description for SAFI 134 [RFC5575bis] 646 to read as follows and to change the reference for it to [this 647 document]: 649 134 VPN dissemination of flow specification rules 651 IANA is requested to create an L2 Flow Spec Component Type registry 652 on the Flow Spec Component Types registries web page as follows: 654 Name: L2 Flow Spec Component Types 655 Reference: [this document] 656 Registration Procedures: 657 0 Reserved 658 1-127 Specification Required 659 128-255 First Come First Served 661 Initial contents: 662 +------+-----------------------+------------------------------+ 663 | type | Reference | description | 664 +------+-----------------------+------------------------------+ 665 | 0 | [this document] | Reserved | 666 | 1 | [this document] | Ethernet Type | 667 | 2 | [this document] | Source MAC | 668 | 3 | [this document] | Destination MAC | 669 | 4 | [this document] | DSAP in LLC | 670 | 5 | [this document] | SSAP in LLC | 671 | 6 | [this document] | Control field in LLC | 672 | 7 | [this document] | SNAP | 673 | 8 | [this document] | VLAN ID | 674 | 9 | [this document] | VLAN PCP | 675 | 10 | [this document] | Inner VLAN ID | 676 | 11 | [this document] | Inner VLAN PCP | 677 | 12 | [this document] | VLAN DEI | 678 | 13 | [this document] | Inner VLAN DEI | 679 | 14 | [this document] | Source MAC Special Bits | 680 | 15 | [this document] | Destination MAC Special Bits| 681 |16-254| [this document] | unassigned | 682 | 255 | [this document] | reserved | 683 +------+-----------------------+------------------------------+ 685 IANA is requested to assign two values from the "BGP Extended 686 Communities Type - extended, transitive" registry [suggested value 687 provided in square brackets]: 689 Type value Name Reference 690 ------------ ------------------------ --------------- 691 TBD1[0x080A] Flow spec VLAN action [this document] 692 TBD2[0x080B] Flow spec TPID action [this document] 694 7. Security Considerations 696 For General BGP Flow-spec Security Considerations, see [RFC5575bis]. 698 VLAN tagging identifies Layer 2 communities which are commonly 699 expected to be isolated except when higher layer connection is 700 provided, such as Layer 3 routing. The ability of the Flow-spec VLAN 701 action to change the VLAN ID in a frame may thus compromise security. 703 8. Acknowledgements 705 The authors wish to acknowledge the important contributions and 706 suggestions of the following: 708 Hannes Gredler, Xiaohu Xu, Zhenbin Li, Lucy Yong, and Feng Dong. 710 9. Contributors 712 Qiandeng Liang 713 Huawei Technologies 714 101 Software Avenue, Yuhuatai District 715 Nanjing 210012 716 China 718 Email: liangqiandeng@huawei.com 720 Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", BCP 14, RFC 2119, DOI 724 10.17487/RFC2119, March 1997, . 727 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border 728 Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 729 10.17487/RFC4271, January 2006, . 732 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN 733 Service (VPLS) Using BGP for Auto-Discovery and Signaling", 734 RFC 4761, DOI 10.17487/RFC4761, January 2007, 735 . 737 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 738 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 739 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 740 . 742 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 743 "Provisioning, Auto-Discovery, and Signaling in Layer 2 744 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 745 10.17487/RFC6074, January 2011, . 748 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 749 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 750 2017, . 752 [FlowSpecOID] Uttaro, J., Alcaide, J., Filsfils, C. Smith, D., 753 Mohapatra, P., draft-ietf-idr-bgp-flowspec-oid, work in 754 progress. 756 [FlowSpecV6] McPherson, D., Raszuk, R., Pithawala, B., 757 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 758 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 759 v6-10. Work in progress. 761 [RFC5575bis] Hares, S., Loibl, C., Raszuk, R., McPherson, D., Bacher, 762 M., "Dissemination of Flow Specification Rules", draft- 763 ietf-idr-rfc5575bis-18, Work in progress. 765 Informative References 767 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 768 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 769 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 770 2015, . 772 [RFC7042bis] Eastlake, D., and J. Abley, "IANA Considerations and 773 IETF Protocol and Documentation Usage for IEEE 802 774 Parameters", draft-eastlake-rfc7042bis, Work in progress. 776 Authors' Addresses 778 Weiguo Hao 779 Huawei Technologies 780 101 Software Avenue, 781 Nanjing 210012 782 China 784 Email: haoweiguo@huawei.com 786 Donald E. Eastlake, 3rd 787 Futurewei Technologies 788 2386 Panoramic Circle 789 Apopka, FL 32703 790 USA 792 Tel: +1-508-333-2270 793 Email: d3e3e3@gmail.com 795 James Uttaro 796 AT&T 798 Email: uttaro@att.com 800 Stephane Litkowski 801 Cisco Systems, Inc. 803 Email: slitkows.ietf@gmail.com 805 Shunwan Zhuang 806 Huawei Technologies 807 Huawei Bld., No.156 Beiqing Rd. 808 Beijing 100095 809 China 811 Email: zhuangshunwan@huawei.com 813 Copyright, Disclaimer, and Additional IPR Provisions 815 Copyright (c) 2019 IETF Trust and the persons identified as the 816 document authors. All rights reserved. 818 This document is subject to BCP 78 and the IETF Trust's Legal 819 Provisions Relating to IETF Documents 820 (http://trustee.ietf.org/license-info) in effect on the date of 821 publication of this document. Please review these documents 822 carefully, as they describe your rights and restrictions with respect 823 to this document. Code Components extracted from this document must 824 include Simplified BSD License text as described in Section 4.e of 825 the Trust Legal Provisions and are provided without warranty as 826 described in the Simplified BSD License.