idnits 2.17.1 draft-ietf-bess-evpn-vpws-fxc-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 7, 2021) is 1047 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) == Unused Reference: 'I-D.ietf-bess-rfc7432bis' is defined on line 674, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-bess-rfc7432bis-00 == Outdated reference: A later version (-20) exists of draft-ietf-rtgwg-bgp-pic-11 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group A. Sajassi, Ed. 3 Internet-Draft P. Brissette 4 Intended status: Standards Track Cisco Systems 5 Expires: December 9, 2021 J. Uttaro 6 AT&T 7 J. Drake 8 Juniper Networks 9 S. Boutros 10 Ciena 11 J. Rabadan 12 Nokia 13 June 7, 2021 15 EVPN VPWS Flexible Cross-Connect Service 16 draft-ietf-bess-evpn-vpws-fxc-03 18 Abstract 20 This document describes a new EVPN VPWS service type specifically for 21 multiplexing multiple attachment circuits across different Ethernet 22 Segments and physical interfaces into a single EVPN VPWS service 23 tunnel and still providing Single-Active and All-Active multi-homing. 24 This new service is referred to as flexible cross-connect service. 25 After a description of the rationale for this new service type, the 26 solution to deliver such service is detailed. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 9, 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 65 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. VPWS Service Identifiers . . . . . . . . . . . . . . . . 7 68 3.2. Flexible Xconnect . . . . . . . . . . . . . . . . . . . . 7 69 3.2.1. Default mode FXC with Multi-homing . . . . . . . . . 8 70 3.3. VLAN-Signaled Flexible Xconnect . . . . . . . . . . . . . 8 71 3.3.1. Local Switching . . . . . . . . . . . . . . . . . . . 9 72 3.4. Service Instantiation . . . . . . . . . . . . . . . . . . 10 73 4. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. EVPN VPWS Service Failure . . . . . . . . . . . . . . . . 13 76 5.2. Attachment Circuit Failure . . . . . . . . . . . . . . . 13 77 5.3. PE Port Failure . . . . . . . . . . . . . . . . . . . . . 14 78 5.4. PE Node Failure . . . . . . . . . . . . . . . . . . . . . 14 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 8.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 87 1. Introduction 89 [RFC8214] describes a solution to deliver P2P services using BGP 90 constructs defined in [RFC7432]. It delivers this P2P service 91 between a pair of Attachment Circuits (ACs), where an AC can 92 designate on a PE, a port, a VLAN on a port, or a group of VLANs on a 93 port. It also leverages multi-homing and fast convergence 94 capabilities of [RFC7432] in delivering these VPWS services. 95 Multi-homing capabilities include the support of single-active and 96 all-active redundancy mode and fast convergence is provided using 97 "mass withdraw" message in control- plane and fast protection 98 switching using prefix independent convergence in data-plane upon 99 node or link failure [I-D.ietf-rtgwg-bgp-pic]. Furthermore, the use 100 of EVPN BGP constructs eliminates the need for multi-segment PW 101 auto-discovery and signaling if the VPWS service need to span across 102 multiple ASes. 104 Some service providers have very large number of ACs (in millions) 105 that need to be back hauled across their MPLS/IP network. These ACs 106 may or may not require tag manipulation (e.g., VLAN translation). 107 These service providers want to multiplex a large number of ACs 108 across several physical interfaces spread across one or more PEs 109 (e.g., several Ethernet Segments) onto a single VPWS service tunnel 110 in order to a) reduce number of EVPN service labels associated with 111 EVPN-VPWS service tunnels and thus the associated OAM monitoring, and 112 b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is 113 the case in [RFC8214]). 115 These service provider want the above functionality without 116 scarifying any of the capabilities of [RFC8214] including single- 117 active and all-active multi-homing, and fast convergence. 119 This document presents a solution based on extensions to [RFC8214] to 120 meet the above requirements. 122 1.1. Terminology 124 MAC: Media Access Control 126 MPLS: Multi Protocol Label Switching 128 OAM: Operations, Administration and Maintenance 130 PE: Provider Edge device 132 CE: Customer Edge device e.g., host or router or switch 134 EVPL: Ethernet Virtual Private Line 136 EPL: Ethernet Private Line 138 ES: Ethernet Segment 140 VPWS: Virtual private wire service 141 EVI: EVPN Instance 143 RT: Route Target 145 VPWS Service Tunnel: It is represented by a pair of EVPN service 146 labels associated with a pair of endpoints. Each label is 147 downstream assigned and advertised by the disposition PE through 148 an Ethernet A-D per-EVI route. The downstream label identifies 149 the endpoint on the disposition PE. A VPWS service tunnel can be 150 associated with many VPWS service identifiers where each 151 identifier is a normalized VID. 153 Single-Active Redundancy Mode: When a device or a network is 154 multi-homed to two or more PEs and when only a single PE in such 155 redundancy group can forward traffic to/from the multi-homed 156 device or network for a given VLAN, then such multi-homing or 157 redundancy is referred to as "Single-Active". 159 All-Active Redundancy Mode: When a device is multi-homed to two or 160 more PEs and when all PEs in such redundancy group can forward 161 traffic to/from the multi-homed device for a given VLAN, then such 162 multi-homing or redundancy is referred to as "All-Active". 164 1.2. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 2. Requirements 172 Two of the main motivations for service providers seeking a new 173 solution are: 1) to reduce number of VPWS service tunnels by 174 multiplexing large number of ACs across different physical interfaces 175 instead of having one VPWS service tunnel per AC, and 2) to reduce 176 the signaling of ACs as much as possible. Besides these two 177 requirements, they also want multi-homing and fast convergence 178 capabilities of [RFC8214]. 180 In [RFC8214], a PE signals an AC indirectly by first associating that 181 AC to a VPWS service tunnel (e.g., a VPWS service instance) and then 182 signaling the VPWS service tunnel via a Ethernet A-D per EVI route 183 with Ethernet Tag field set to a 24-bit VPWS service instance 184 identifier (which is unique within the EVI) and ESI field set to a 185 10-octet identifier of the Ethernet Segment corresponding to that AC. 187 Therefore, a PE device that receives such EVPN routes, can associate 188 the VPWS service tunnel to the remote Ethernet Segment, and when the 189 remote ES fails and the PE receives the "mass withdraw" message 190 associated with the failed ES per [RFC7432], it can update its BGP 191 path list for that VPWS service tunnel quickly and achieve fast 192 convergence for multi-homing scenarios. Even if fast convergence 193 were not needed, there would still be a need for signaling each AC 194 failure (via its corresponding VPWS service tunnel) associated with 195 the failed ES, so that the BGP path list for each of them gets 196 updated accordingly and the packets are sent to backup PE (in case of 197 single- active multi-homing) or to other PEs in the redundancy group 198 (in case of all-active multi-homing). In absence of updating the BGP 199 path list, the traffic for that VPWS service tunnel will be 200 black-holed. 202 When a single VPWS service tunnel multiplexes many ACs across number 203 of Ethernet Segments (number of physical interfaces) and the ACs are 204 not signaled via EVPN BGP to remote PE devices, then the remote PE 205 devices neither know the association of the received Ethernet Segment 206 to these ACs (and in turn to their local ACs) nor they know the 207 association of the VPWS service tunnel (e.g., EVPN service label) to 208 the far-end ACs - i.e, the remote PEs only know the association of 209 their local ACs to the VPWS service tunnel but not the far-end ACs. 210 Thus upon a connectivity failure to the ES, they don't know how to 211 redirect traffic via another multi-homing PE to that ES. In other 212 words, even if an ES failure is signaled via EVPN to the remote PE 213 devices, they don't know what to do with such message because they 214 don't know the association among the remote ES, the remote ACs, and 215 the VPWS service tunnel. 217 In order to address this issue when multiplexing large number of ACs 218 onto a single VPWS service tunnel, two mechanisms are devised: one to 219 support VPWS services between two single-homed endpoints and another 220 one to support VPWS services where one of the endpoints is multi- 221 homed. An endpoint can be an AC, MAC-VRF, IP-VRF, global table, or 222 etc. 224 For single-homed endpoints, it is OK not to signal each AC in BGP 225 because upon connection failure to the ES, there is no alternative 226 path to that endpoint. However, the ramification for not signaling 227 an AC failure is that the traffic destined to the failed AC, is sent 228 over MPLS/IP core and then gets discarded at the destination PE - 229 i.e., it can waste network resources. However, when there is a 230 connection failure, the application layer will eventually stop 231 sending traffic making transient this waste of network resources. 232 Section 3.2 describes a solution for such single-homing VPWS service. 234 For VPWS services where one of the endpoints is multi-homed, there 235 are two options: 237 1) to signal each AC via BGP so that the path list can be updated 238 upon a failure that impacts those ACs. This solution is described in 239 Section 3.3 and it is called VLAN-signaled flexible cross-connect 240 service. 242 2) to bundle several ACs on an ES together per destination end-point 243 (e.g., ES, MAC-VRF, etc.) and associated such bundle to a single VPWS 244 service tunnel. This is similar to VLAN-bundle service interface 245 described in [RFC8214]. This solution is described in Section 3.2.1. 247 3. Solution 249 This section describes a solution for providing a new VPWS service 250 between two PE devices where a large number of ACs (e.g., VLANs) that 251 span across many Ethernet Segments (i.e., physical interfaces) on 252 each PE are multiplex onto a single P2P EVPN service tunnel. Since 253 multiplexing is done across several physical interfaces, there can be 254 overlapping VLAN IDs across these interfaces; therefore, in such 255 scenarios, the VLAN IDs (VIDs) MUST be translated into unique VIDs to 256 avoid collision. Furthermore, if the number of VLANs that are 257 getting multiplex onto a single VPWS service tunnel exceed 4095, then 258 a single tag to double tag translation MUST be performed. This 259 translation of VIDs into unique VIDs (either single or double) is 260 referred to as "VID normalization". 262 When single normalized VID is used, the lower 12-bit of Ethernet tag 263 field in EVPN routes is set to that VID and when double normalized 264 VID is used, the lower 12-bit of Ethernet tag field is set to inner 265 VID and the higher 12-bit is set to the outer VID. As in [RFC8214], 266 12-bit and 24-bit VPWS service instance identifiers representing 267 normalised VIDs MUST be right-aligned. 269 Since there is only a single EVPN VPWS service tunnel associated with 270 many normalized VIDs (either single or double) across multiple 271 physical interfaces, MPLS lookup at the disposition PE is no longer 272 sufficient to forward the packet to the right egress 273 endpoint/interface. Therefore, in addition to an EVPN label lookup 274 corresponding to the VPWS service tunnel, a VID lookup (either single 275 or double) is also required. On the disposition PE, one can think of 276 the lookup of EVPN label results in identification of a VID-VRF, and 277 the lookup of normalized VID(s) in that table, results in 278 identification of egress endpoint/interface. The tag manipulation 279 (translation from normalized VID(s) to local VID) can be performed 280 either as part of the VID table lookup or at the egress interface 281 itself. 283 Since VID lookup (single or double) needs to be performed at the 284 disposition PE, then VID normalization MUST be performed prior to the 285 MPLS encapsulation on the ingress PE. This requires that both 286 imposition and disposition PE devices be capable of VLAN tag 287 manipulation, such as re-write (single or double), addition, deletion 288 (single or double) at their endpoints (e.g., their ES's, MAC-VRFs, 289 IP-VRFs, etc.). 291 3.1. VPWS Service Identifiers 293 In [RFC8214], a unique value in the context of each PE's EVI is 294 signaled. The 32-bit Ethernet Tag ID field MUST be set to this VPWS 295 service instance identifier value. 296 For FXC, Ethernet Tag ID field value may represent: 298 o VLAN-Bundle : a unique value for a group of VLANs ; 300 o VLAN-Aware Bundle : a unique value for individual VLANs, and may 301 be considered same as the normalised VID 303 Both the VPWS service instance identifier and normalised VID are 304 carried in the Ethernet Tag ID field of the Ethernet A-D per EVI 305 route. For FXC, in the case of a 12-bit ID the VPWS service instance 306 identifier is the same as the single-tag normalised VID and will be 307 the same on both PEs. Similarly in the case of a 24-bit ID, the VPWS 308 service instance identifier is the same as the double-tag normalised 309 VID. 311 3.2. Flexible Xconnect 313 In this mode of operation, many ACs across several Ethernet Segments 314 are multiplex into a single EVPN VPWS service tunnel represented by a 315 single VPWS service ID. This is the default mode of operation for 316 FXC and the participating PEs do not need to signal the VLANs 317 (normalized VIDs) in EVPN BGP. 319 With respect to the data-plane aspects of the solution, both 320 imposition and disposition PEs are aware of the VLANs as the 321 imposition PE performs VID normalization and the disposition PE does 322 VID lookup and translation. In this solution, there is only a single 323 P2P EVPN VPWS service tunnel between a pair of PEs for a set of ACs. 325 As discussed previously, since the EVPN VPWS service tunnel is used 326 to multiplex ACs across different ES's (e.g., physical interfaces), 327 the EVPN label alone is not sufficient for proper forwarding of the 328 received packets (over MPLS/IP network) to egress interfaces. 329 Therefore, normalized VID lookup is required in the disposition 330 direction to forward packets to their proper egress end-points - 331 i.e., the EVPN label lookup identifies a VID-VRF and subsequently, 332 the normalized VID lookup in that table, identifies the egress 333 interface. 335 This mode of operation is only suitable for single-homing because in 336 multi-homing the association between EVPN VPWS service tunnel and 337 remote AC changes during the failure and therefore the VLANs 338 (normalized VIDs) need to be signaled. 340 In this solution, on each PE, the single-homing ACs represented by 341 their normalized VIDs are associated with a single EVPN VPWS service 342 tunnel (in a given EVI). The EVPN route that gets generated is an 343 Ethernet A-D per EVI route with ESI=0, Ethernet Tag field set to VPWS 344 service instance ID, MPLS label field set to dynamically generated 345 EVPN service label representing the EVPN VPWS service tunnel. This 346 route is sent with an RT representing the EVI. This RT can be 347 auto-generated from the EVI per section 5.1.2.1 of [RFC8365]. 348 Furthermore, this route is sent with the EVPN Layer-2 Extended 349 Community defined in section 3.1 of [RFC8214] with two new flags 350 (defined in Section 4) that indicate: 1) this VPWS service tunnel is 351 for default Flexible Cross-Connect, and 2) normalized VID type 352 (single versus double). The receiving PE uses these new flags for 353 consistency check and MAY generate an alarm if it detects 354 inconsistency but doesn't bring down the VPWS service. 356 It should be noted that in this mode of operation, a single 357 Ethernet A-D per EVI route is sent upon configuration of the first AC 358 (ie, normalized VID). Later, when additional ACs are configured and 359 associated with this EVPN VPWS service tunnel, the PE does not 360 advertise any additional EVPN BGP routes. The PE only associates 361 locally these ACs with the already created VPWS service tunnel. 363 3.2.1. Default mode FXC with Multi-homing 365 The default FXC mode can be used for multi-homing. In this mode, a 366 group of normalized VIDs (ACs) on a single Ethernet segment that are 367 destined to a single endpoint are multiplexed into a single EVPN VPWS 368 service tunnel represented by a single VPWS service ID. When the 369 default FXC mode is used for multi-homing, instead of a single EVPN 370 VPWS service tunnel, there can be many service tunnels per pair of 371 PEs - i.e, there is one tunnel per group of VIDs per pair of PEs and 372 there can be many groups between a pair of PEs, thus resulting in 373 many EVPN service tunnels. 375 3.3. VLAN-Signaled Flexible Xconnect 377 In this mode of operation, just as the default FXC mode in 378 Section 3.2, many normalized VIDs (ACs) across several different 379 ES's/interfaces are multiplexed into a single EVPN VPWS service 380 tunnel; however, this single tunnel is represented by many VPWS 381 service IDs (one per normalized VID) and these normalized VIDs are 382 signaled using EVPN BGP. 384 In this solution, on each PE, the multi-homing ACs represented by 385 their normalized VIDs are configured with a single EVI. There is no 386 need to configure VPWS service instance ID in here as it is the same 387 as the normalized VID. For each normalized VID on each ES, the PE 388 generates an Ethernet A-D per EVI route where ESI field represents 389 the ES ID, the Ethernet Tag field is set to the normalized VID, MPLS 390 label field is set to dynamically generated EVPN label representing 391 the P2P EVPN service tunnel and it is the same label for all the ACs 392 that are multiplexed into a single EVPN VPWS service tunnel. This 393 route is sent with an RT representing the EVI. As before, this RT 394 can be auto-generated from the EVI per section 5.1.2.1 of [RFC8365]. 395 Furthermore, this route is sent with the EVPN Layer-2 Extended 396 Community defined in section 3.1 of [RFC8214] with two new flags 397 (defined in Section 4) that indicate: 1) this VPWS service tunnel is 398 for VLAN-signaled Flexible Cross-Connect, and 2) normalized VID type 399 (single versus double). The receiving PE uses these new flags for 400 consistency check and MAY generate an alarm if it detects 401 inconsistency but doesn't bring down the VPWS service. 403 It should be noted that in this mode of operation, the PE sends a 404 single Ethernet A-D per EVI route for each AC that is configured - 405 i.e., each normalized VID that is configured per ES results in 406 generation of an EVPN Ethernet A-D per EVI. 408 This mode of operation provides automatic cross checking of 409 normalized VIDs used for EVPL services because these VIDs are 410 signaled in EVPN BGP. For example, if the same normalized VID is 411 configured on three PE devices (instead of two) for the same EVI, 412 then when a PE receives the second Ethernet A-D per EVI route, it 413 generates an error message unless the two Ethernet A-D per EVI routes 414 include the same ESI. Such cross-checking is not feasible in default 415 FXC mode because the normalized VIDs are not signaled. 417 3.3.1. Local Switching 419 When cross-connection is between two ACs belonging to two multi-homed 420 Ethernet Segments on the same set of multi-homing PEs, then 421 forwarding between the two ACs MUST be performed locally during 422 normal operation (e.g., in absence of a local link failure) - i.e., 423 the traffic between the two ACs MUST be locally switched within the 424 PE. 426 In terms of control plane processing, this means that when the 427 receiving PE receives an Ethernet A-D per-EVI route whose ESI is a 428 local ESI, the PE does not alter its forwarding state based on the 429 received route. This ensures that the local switching takes 430 precedence over forwarding via MPLS/IP network. This scheme of 431 locally switched preference is consistent with baseline EVPN 432 [RFC7432] where it describes the locally switched preference for 433 MAC/IP routes. 435 In such scenarios, the Ethernet A-D per EVI route should be 436 advertised with the MPLS label either associated with the destination 437 Attachment Circuit or with the destination Ethernet Segment in order 438 to avoid any ambiguity in forwarding. In other words, the MPLS label 439 cannot represent the same VID-VRF used in Section 3.3 because the 440 same normalized VID can be reachable via two Ethernet Segments. In 441 case of using MPLS label per destination AC, then this same solution 442 can be used for VLAN-based VPWS or VLAN-bundle VPWS services per 443 [RFC8214]. 445 3.4. Service Instantiation 447 The V field defined in Section 4 is OPTIONAL. However, when 448 transmitted, its value could be flagging an error condition which may 449 result in an operational issue. Notification to operator of an error 450 is not sufficient, the VPWS service tunnel must not be established. 452 If both PEs of a VPWS tunnel are signaling a matching Normalised VID 453 in control plane, yet one is operating in single tag and the other in 454 double tag mode, the signaling of V-bit allows for detecting and 455 preventing this tunnel instantiation. 457 If single VID normalisation is signaled in the Ethernet Tag ID field 458 (12-bits) yet dataplane is operating based double tags, the VID 459 normalisation applies only to outer tag. If double VID normalisation 460 is signaled in the Ethernet Tag ID field (24-bits), VID normalisation 461 applies to both inner and outer tags. 463 4. BGP Extensions 465 This draft uses the EVPN Layer-2 attribute extended community defined 466 in [RFC8214] with two additional flags added to this EC as described 467 below. This EC is sent with Ethernet A-D per EVI route per 468 Section 3, and SHOULD be sent for Single-Active and All-Active 469 redundancy modes. 471 +-------------------------------------------+ 472 | Type (0x06) / Sub-type (0x04) (2 octets) | 473 +-------------------------------------------+ 474 | Control Flags (2 octets) | 475 +-------------------------------------------+ 476 | L2 MTU (2 octets) | 477 +-------------------------------------------+ 478 | Reserved (2 octets) | 479 +-------------------------------------------+ 481 1 1 1 1 1 1 482 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | MBZ | V | M |-|C|P|B| (MBZ = MUST Be Zero) 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 The following bits in the Control Flags are defined; the remaining 488 bits MUST be set to zero when sending and MUST be ignored when 489 receiving this community. 491 Name Meaning 492 --------------------------------------------------------------- 493 B,P,C per definition in [RFC8214] 495 - reserved for Flow-label (draft-ietf-bess-rfc7432bis) 497 M 00 mode of operation as defined in [RFC8214] 498 01 VLAN-Signaled FXC 499 10 Default FXC 501 V 00 operating per [RFC8214] 502 01 single-VID normalization 503 10 double-VID normalization 505 The M and V fields are OPTIONAL. The M field is ignored at reception 506 for forwarding purposes and is used for error notifications. 508 5. Failure Scenarios 510 Two examples will be used as an example to analyze the failure 511 scenarios. 513 The first scenario is depicted in Figure 1 and shows the 514 VLAN-signaled FXC mode with Multi-Homing. In this example: 516 o CE1 is connected to PE1 and PE2 via (port,vid)=(p1,1) and (p3,3) 517 respectively. CE1's VIDs are normalized to value 1 on both PEs, 518 and CE1 is Xconnected to CE3's VID 1 at the remote end. 520 o CE2 is connected to PE1 and PE2 via ports p2 and p4 respectively: 522 * (p2,1) and (p4,3) identify the ACs that are used to Xconnect 523 CE2 to CE4's VID 2, and are normalized to value 2. 525 * (p2,2) and (p4,4) identify the ACs that are used to Xconnect 526 CE2 to CE5's VID 3, and are normalized to value 3. 528 In this scenario, PE1 and PE2 advertise an Ethernet A-D per EVI route 529 per normalized VID (values 1, 2 and 3), however only two VPWS Service 530 Tunnels are needed: VPWS Service Tunnel 1 (sv.T1) between PE1's FXC 531 service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) between 532 PE2's FXC and PE3's FXC. 534 N.VID 1,2,3 +---------------------+ 535 PE1 | | 536 +---------+ IP/MPLS | 537 +-----+ VID1 p1 | +-----+ | + 538 | CE1 |------------| FXC | | sv.T1 PE3 +-----+ 539 | | /\ | | |=======+ +----------+ +--| CE3 | 540 +-----+\ +||---| | | \ | | 1/ | | 541 VID3\ / ||---| | | \ | +-----+ | / +-----+ 542 \ / /\/ | +-----+ | +=====| FXC |----+ 543 \ / p2 +---------+ | | | | 2 +-----+ 544 /\ | | |----------| CE4 | 545 / /\ +---------+ +======| | | | | 546 / / \p3 | +-----+ | / | | | | +-----+ 547 VIDs1,2 / +----| FXC | / | | |---+ 548 +-----+ / /\ | | |======+ | +-----+ |\3 +-----+ 549 | CE2 |-----||-----| | | sv.T2 | | \ | CE5 | 550 | |-----||-----| | | +----------+ +---| | 551 +-----+ \/ | +-----+ | | +-----+ 552 VIDs3,4 p4 +---------+ | 553 PE2 | | 554 N.VID 1,2,3 +------------------+ 556 Figure 1: VLAN-Signaled Flexible Xconnect 558 The second scenario is a default Flexible Xconnect with Multi- Homing 559 solution and it is depicted in Figure 2. In this case, the same VID 560 Normalization as in the previous example is performed, however there 561 is not an individual Ethernet A-D per EVI route per normalized VID, 562 but per bundle of ACs on an ES. That is, PE1 will advertise two 563 Ethernet A-D per EVI routes: the first one will identify the ACs on 564 p1's ES and the second one will identify the AC2 in p2's ES. 565 Similarly, PE2 will advertise two Ethernet A-D per EVI routes. 567 N.VID 1,2,3 +---------------------+ 568 PE1 | | 569 +---------+ IP/MPLS | 570 +-----+ VID1 p1 | +-----+ | sv.T1 + 571 | CE1 |-------------| FXC |======+ PE3 +-----+ 572 | | /\ | | | | \ +----------+ +--| CE3 | 573 +-----+\ +||---| | sv.T2 \ | | 1/ | | 574 VID3\ / ||---| |=====+ \ | +-----+ | / +-----+ 575 \ // \/ | +-----+ | \ +====| FXC |----+ 576 \ / p2 +---------+ +======| | | 2 +-----+ 577 /\ | | |----------| CE4 | 578 / /\ +---------+ +=====| | | | | 579 / / \p3 | +-----+ sv.T3 / +====| | | +-----+ 580 VIDs1,2 / +----| FXC |=======+ / | | |---+ 581 +-----+ / /\ | | | | / | +-----+ |\3 +-----+ 582 | CE2 |-----||---| | | sv.T4 / | | \ | CE5 | 583 | |-----||---| | |======+ +----------+ +---| | 584 +--VIDs3,4 \/ | +-----+ | | +-----+ 585 p4 +---------+ | 586 PE2 | | 587 N.VID 1,2,3 +-------------------+ 589 Figure 2: Default Flexible Xconnect 591 5.1. EVPN VPWS Service Failure 593 The failure detection of an EVPN VPWS service can be performed via 594 OAM mechanisms such as VCCV-BFD and upon such failure detection, the 595 switch over procedure to the backup S-PE is the same as the one 596 described above. 598 5.2. Attachment Circuit Failure 600 In case of AC Failure, the VLAN-Signaled and default FXC modes behave 601 in a different way: 603 o VLAN-signaled FXC (Figure 1): a VLAN or AC failure, e.g. VID1 on 604 CE2, triggers the withdrawal of the Ethernet A-D per EVI route for 605 the corresponding Normalized VID, that is, Ethernet-Tag 2. When 606 PE3 receives the route withdrawal, it will remove PE1 from its 607 path-list for traffic coming from CE4. 609 o Default FXC (Figure 2): a VLAN or AC failure is not signaled in 610 the default mode, therefore in case of an AC failure, e.g. VID1 611 on CE2, nothing prevents PE3 from sending CE4's traffic to PE1, 612 creating a black-hole. Application layer OAM may be used if per- 613 VLAN fault propagation is required in this case. 615 5.3. PE Port Failure 617 In case of PE port Failure, the failure will be signaled and the 618 other PE will take over in both cases: 620 o VLAN-signaled FXC (Figure 1): a port failure, e.g. p2, triggers 621 the withdrawal of the Ethernet A-D per EVI routes for Normalized 622 VIDs 2 and 3, as well as the withdrawal of the Ethernet A-D per ES 623 route for p2's ES. Upon receiving the fault notification, PE3 624 will withdraw PE1 from its path-list for the traffic coming from 625 CE4 and CE5. 627 o Default FXC (Figure 2): a port failure, e.g. p2, is signaled by 628 route for sv.T2 will also be withdrawn. Upon receiving the fault 629 notification, PE3 will remove PE1 from its path-list for traffic 630 coming from CE4 and CE5. 632 5.4. PE Node Failure 634 In the case of PE node failure, the operation is similar to the steps 635 described above, albeit that EVPN route withdrawals are performed by 636 the Route Reflector instead of the PE. 638 6. Security Considerations 640 Since this document describes a muxing capability which leverages 641 EVPN-VPWS signaling, no additional functionality beyond the muxing 642 service is added and thus no additional security considerations are 643 needed beyond what is already specified in [RFC8214]. 645 7. IANA Considerations 647 This document requests allocation of bits 4-7 in the "EVPN Layer 2 648 Attributes Control Flags" registry with names M and V: 650 M Signaling mode of operation (2 bits) 651 V VLAN-ID normalisation (2 bits) 653 8. References 655 8.1. Normative References 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, 660 . 662 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 663 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 664 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 665 2015, . 667 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 668 Rabadan, "Virtual Private Wire Service Support in Ethernet 669 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 670 . 672 8.2. Informative References 674 [I-D.ietf-bess-rfc7432bis] 675 Sajassi, A., Drake, J., and J. Rabadan, "BGP MPLS-Based 676 Ethernet VPN", draft-ietf-bess-rfc7432bis-00 (work in 677 progress), December 2020. 679 [I-D.ietf-rtgwg-bgp-pic] 680 Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix 681 Independent Convergence", draft-ietf-rtgwg-bgp-pic-11 682 (work in progress), February 2020. 684 [RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R., 685 Uttaro, J., and W. Henderickx, "A Network Virtualization 686 Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365, 687 DOI 10.17487/RFC8365, March 2018, 688 . 690 Appendix A. Contributors 692 In addition to the authors listed on the front page, the following 693 co-authors have also contributed substantially to this document: 695 Wen Lin 696 Juniper Networks 698 EMail: wlin@juniper.net 700 Luc Andre Burdet 701 Cisco 703 EMail: lburdet@cisco.com 705 Authors' Addresses 707 Ali Sajassi (editor) 708 Cisco Systems 710 Email: sajassi@cisco.com 712 Patrice Brissette 713 Cisco Systems 715 Email: pbrisset@cisco.com 717 James Uttaro 718 AT&T 720 Email: uttaro@att.com 722 John Drake 723 Juniper Networks 725 Email: jdrake@juniper.net 727 Sami Boutros 728 Ciena 730 Email: sboutros@ciena.com 732 Jorge Rabadan 733 Nokia 735 Email: jorge.rabadan@nokia.com