idnits 2.17.1 draft-sajassi-bess-evpn-vpws-fxc-02.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 (February 10, 2018) is 2260 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Workgroup A. Sajassi 3 INTERNET-DRAFT P. Brissette 4 Intended Status: Standards Track Cisco 5 J. Uttaro 6 ATT 7 J. Drake 8 W. Lin 9 Juniper 10 S. Boutros 11 VMWare 12 J. Rabadan 13 Nokia 15 Expires: August 10, 2018 February 10, 2018 17 EVPN VPWS Flexible Cross-Connect Service 18 draft-sajassi-bess-evpn-vpws-fxc-02.txt 20 Abstract 22 This document describes a new EVPN VPWS service type specifically for 23 multiplexing multiple attachment circuits across different Ethernet 24 Segments and physical interfaces into a single EVPN VPWS service 25 tunnel and still providing Single-Active and All-Active multi-homing. 26 This new service is referred to as flexible cross-connect service. It 27 also describes the rational for this new service type as well as a 28 solution to deliver such service. 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as 38 Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/1id-abstracts.html 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 Copyright and License Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 4.1 VLAN-Unaware Flexible Xconnect - Single-Homing . . . . . . . 7 72 4.2 VLAN-Aware Flexible Xconnect . . . . . . . . . . . . . . . . 8 73 4.2.1 Local Switching . . . . . . . . . . . . . . . . . . . . 9 74 4.3 VLAN-Unaware Flexible Xconnect - Multi-Homing . . . . . . . 9 75 5. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11 77 6.1 EVPN VPWS service Failure . . . . . . . . . . . . . . . . . 13 78 6.2 Attachment Circuit Failure . . . . . . . . . . . . . . . . . 13 79 6.3 PE Port Failure . . . . . . . . . . . . . . . . . . . . . . 14 80 6.4 PE Node Failure . . . . . . . . . . . . . . . . . . . . . . 14 81 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 82 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 83 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 85 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 88 1 Introduction 90 [RFC8214] describes a solution to deliver P2P services using BGP 91 constructs defined in [RFC7432]. It delivers this P2P service between 92 a pair of Attachment Circuits (ACs), where an AC can designate on a 93 PE, a port, a VLAN on a port, or a group of VLANs on a port. It also 94 leverages multi-homing and fast convergence capabilities of [RFC7432] 95 in delivering these VPWS services. Multi-homing capabilities include 96 the support of single-active and all-active redundancy mode and fast 97 convergence is provided using "mass withdraw" message in control- 98 plane and fast protection switching using prefix independent 99 convergence in data-plane upon node or link failure [BGP-PIC]. 100 Furthermore, the use of EVPN BGP constructs eliminates the need for 101 multi-segment PW auto-discovery and signaling if the VPWS service 102 need to span across 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 MAC: Media Access Control 130 MPLS: Multi Protocol Label Switching 132 OAM: Operations, Administration and Maintenance 134 PE: Provide Edge Node 135 CE: Customer Edge device e.g., host or router or switch 137 EVPL: Ethernet Virtual Private Line 139 EPL: Ethernet Private Line 141 ES: Ethernet Segment 143 VPWS: Virtual private wire service 145 EVI: EVPN Instance 147 VPWS Service Tunnel: It is represented by a pair of EVPN service 148 labels associated with a pair of endpoints. Each label is downstream 149 assigned and advertised by the disposition PE through an Ethernet A-D 150 per-EVI route. The downstream label identifies the endpoint on the 151 disposition PE. A VPWS service tunnel can be associated with many 152 VPWS service identifiers for VLAN-aware VPWS service where each 153 identifier is a normalized VID. 155 Single-Active Mode: When a device or a network is multi-homed to two 156 or more PEs and when only a single PE in such redundancy group can 157 forward traffic to/from the multi-homed device or network for a given 158 VLAN, then such multi-homing or redundancy is referred to as "Single- 159 Active". 161 All-Active: When a device is multi-homed to two or more PEs and when 162 all PEs in such redundancy group can forward traffic to/from the 163 multi-homed device for a given VLAN, then such multi-homing or 164 redundancy is referred to as "All-Active". 166 2 Requirements 168 Two of the main motivations for service providers seeking a new 169 solution are: 1) to reduce number of VPWS service tunnels by 170 multiplexing large number of ACs across different physical interfaces 171 instead of having one VPWS service tunnel per AC, and 2) to reduce 172 the signaling of ACs as much as possible. Besides these two 173 requirements, they also want multi-homing and fast convergence 174 capabilities of [RFC8214]. 176 In [RFC8214], a PE signals an AC indirectly by first associating that 177 AC to a VPWS service tunnel (e.g., a VPWS service instance) and then 178 signaling the VPWS service tunnel via a per-EVI Ethernet AD route 179 with Ethernet Tag field set to a 24-bit VPWS service instance 180 identifier (which is unique within the EVI) and ESI field set to a 181 10-octet identifier of the Ethernet Segment corresponding to that AC. 183 Therefore, a PE device that receives such EVPN routes, can associate 184 the VPWS service tunnel to the remote Ethernet Segment, and when the 185 remote ES fails and the PE receives the "mass withdraw" message 186 associated with the failed ES per [RFC7432], it can update its BGP 187 path list for that VPWS service tunnel quickly and achieve fast 188 convergence for multi-homing scenarios. Even if fast convergence were 189 not needed, there would still be a need for signaling each AC failure 190 (via its corresponding VPWS service tunnel) associated with the 191 failed ES, so that the BGP path list for each of them gets updated 192 accordingly and the packets are sent to backup PE (in case of single- 193 active multi-homing) or to other PEs in the redundancy group (in case 194 of all-active multi-homing). In absence of updating the BGP path 195 list, the traffic for that VPWS service tunnel will be black-holed. 197 When a single VPWS service tunnel multiplexes many ACs across number 198 of Ethernet Segments (number of physical interfaces) and the ACs are 199 not signaled via EVPN BGP to remote PE devices, then the remote PE 200 devices neither know the association of the received Ethernet Segment 201 to these ACs (and in turn to their local ACs) nor they know the 202 association of the VPWS service tunnel (e.g., EVPN service label) to 203 the far-end ACs - i.e, the remote PEs only know the association of 204 their local ACs to the VPWS service tunnel but not the far-end ACs. 205 Thus upon a connectivity failure to the ES, they don't know how to 206 redirect traffic via another multi-homing PE to that ES. In other 207 words, even if an ES failure is signaled via EVPN to the remote PE 208 devices, they don't know what to do with such message because they 209 don't know the association among the remote ES, the remote ACs, and 210 the VPWS service tunnel. 212 In order to address this issue when multiplexing large number of ACs 213 onto a single VPWS service tunnel, two mechanisms are devised: one to 214 support VPWS services between two single-homed endpoints and another 215 one to support VPWS services where one of the endpoints is multi- 216 homed. An endpoint can be an AC, MAC-VRF, IP-VRF, global table, or 217 etc. 219 For single-homed endpoints, it is OK not to signal each AC in BGP 220 because upon connection failure to the ES, there is no alternative 221 path to that endpoint. However, the ramification for not signaling an 222 AC failure is that the traffic destined to the failed AC, is sent 223 over MPLS/IP core and then gets discarded at the destination PE - 224 i.e., it can waste network resources. However, when there is a 225 connection failure, the application layer will eventually stop 226 sending traffic and thus this wastage of network resources should be 227 transient. Section 4.1 describes a solution for such single-homing 228 VPWS service. 230 For VPWS services where one of the endpoints is multi-homed, there 231 are two options: 233 1) to signal each AC via BGP so that the path list can be updated 234 upon a failure that impacts those ACs. This solution is described in 235 section 4.2 and it is called VLAN-Aware flexible cross-connect 236 service. 238 2) to bundle several ACs on an ES together per destination end-point 239 (e.g., ES, MAC-VRF, etc.) and associated such bundle to a single VPWS 240 service tunnel. This is similar to VLAN-bundle service interface 241 described in [RFC8214]. This solution is described in section 4.3. 243 4 Solution 245 This section describes a solution for providing a new VPWS service 246 between two PE devices where a large number of ACs (e.g., VLANs) that 247 span across many Ethernet Segments (i.e., physical interfaces) on 248 each PE are multiplex onto a single P2P EVPN service tunnel. Since 249 multiplexing is done across several physical interfaces, there can be 250 overlapping VLAN IDs across these interfaces; therefore, in such 251 scenarios, the VLAN IDs (VIDs) MUST be translated into unique VIDs to 252 avoid collision. Furthermore, if the number of VLANs that are getting 253 multiplex onto a single VPWS service tunnel, exceed 4K, then a single 254 tag to double tag translation MUST be performed. This translation of 255 VIDs into unique VIDs (either single or double) is referred to as 256 "VID normalization". When single normalized VID is used, the lower 257 12-bit of Ethernet tag field in EVPN routes is set to that VID and 258 when double normalized VID is used, the lower 12-bit of Ethernet tag 259 field is set to inner VID and the higher 12-bit is set to the outer 260 VID. 262 Since there is only a single EVPN VPWS service tunnel associated with 263 many normalized VIDs (either single or double) across multiple 264 physical interfaces, MPLS lookup at the disposition PE is no longer 265 sufficient to forward the packet to the right egress 266 endpoint/interface. Therefore, in addition to an EVPN label lookup 267 corresponding to the VPWS service tunnel, a VID lookup (either single 268 or double) is also required. On the disposition PE, one can think of 269 the lookup of EVPN label results in identification of a VID-VRF, and 270 the lookup of normalized VID(s) in that table, results in 271 identification of egress endpoint/interface. The tag manipulation 272 (translation from normalized VID(s) to local VID) can be performed 273 either as part of the VID table lookup or at the egress interface 274 itself. 276 Since VID lookup (single or double) needs to be performed at the 277 disposition PE, then VID normalization MUST be performed prior to the 278 MPLS encapsulation on the ingress PE. This requires that both 279 imposition and disposition PE devices be capable of VLAN tag 280 manipulation, such as re-write (single or double), addition, deletion 281 (single or double) at their endpoints (e.g., their ES's, MAC-VRFs, 282 IP-VRFs, etc.). 284 4.1 VLAN-Unaware Flexible Xconnect - Single-Homing 286 In this mode of operation, many ACs across several Ethernet Segments 287 are multiplex into a single EVPN VPWS service tunnel represented by a 288 single VPWS service ID. VLAN-Unaware mode for this solution is with 289 respect to the BGP signaling aspects and it means that VLANs 290 (normalized VIDs) are not signaled via EVPN BGP among the PEs. With 291 respect to the data-plane aspects of the solution, both imposition 292 and disposition PEs are aware of the VLANs as the imposition PE 293 performs VID normalization and the disposition PE does VID lookup and 294 translation. In this solution, there is only a single P2P EVPN VPWS 295 service tunnel between a pair of PEs for a set of ACs that are 296 single-homed. 298 As discussed previously, since the EVPN VPWS service tunnel is used 299 to multiplex ACs across different ES's (e.g., physical interfaces), 300 the EVPN label alone is not sufficient for proper forwarding of the 301 received packets (over MPLS/IP network) to egress interfaces. 302 Therefore, normalized VID lookup is required in the disposition 303 direction to forward packets to their proper egress end-points - 304 i.e., the EVPN label lookup identifies a VID-VRF and subsequently, 305 the normalized VID lookup in that table, identifies the egress 306 interface. 308 In this solution, on each PE, the single-homing ACs represented by 309 their normalized VIDs are associated with a single EVPN VPWS service 310 tunnel (in a given EVI). The EVPN route that gets generated is an 311 EVPN Ethernet AD per EVI route with ESI=0, Ethernet Tag field set to 312 VPWS service instance ID, MPLS label field set to dynamically 313 generated EVPN service label representing the EVPN VPWS service 314 tunnel. This route is sent with an RT representing the EVI. This RT 315 can be auto-generated from the EVI per section 5.1.2.1 of [EVPN- 316 Overlay]. Furthermore, this route is sent with the EVPN Layer-2 317 Extended Community defined in section 3.1 of [RFC8214] with two new 318 flags (defined in section 5) that indicate: 1) this VPWS service 319 tunnel is for VLAN-unaware Flexible Cross-Connect, and 2) normalized 320 VID type (single versus double). The receiving PE uses these new 321 flags for consistency check and MAY generate an alarm if it detects 322 inconsistency but doesn't bring down the VPWS service because such 323 inconsistency may be intentional - i.e., one side is configured for 324 VLAN-aware VPWS service and another side is configured for VLAN- 325 unaware VPWS service. 327 It should be noted that in this mode of operation, a single Ethernet 328 AD per EVI route is sent upon configuration of the first AC (ie, 329 normalized VID). Later, when additional ACs are configured and 330 associated with this EVPN VPWS service tunnel, the PE does not 331 advertise any additional EVPN BGP routes. The PE only associates 332 locally these ACs with the already created VPWS service tunnel. 334 4.2 VLAN-Aware Flexible Xconnect 336 In this mode of operation, just as the VLAN-unaware mode, many 337 normalized VIDs (ACs) across several different ES's/interfaces are 338 multiplexed into a single EVPN VPWS service tunnel; however, this 339 single tunnel is represented by many VPWS service IDs (one per 340 normalized VID) and these normalized VIDs are signaled using EVPN 341 BGP. 343 In this solution, on each PE, the multi-homing ACs represented by 344 their normalized VIDs are configured with a single EVI. There is no 345 need to configure VPWS service instance ID in here as it is the same 346 as the normalized VID. For each normalized VID on each ES, the PE 347 generates an EVPN Ethernet AD per EVI route where ESI field 348 represents the ES ID, the Ethernet Tag field is set to the normalized 349 VID, MPLS label field is set to dynamically generated EVPN label 350 representing the P2P EVPN service tunnel and it is the same label for 351 all the ACs that are multiplexed into a single EVPN VPWS service 352 tunnel. This route is sent with an RT representing the EVI. As 353 before, this RT can be auto-generated from the EVI per section 354 5.1.2.1 of [EVPN-Overlay]. Furthermore, this route is sent with the 355 EVPN Layer-2 Extended Community defined in section 3.1 of [RFC8214] 356 with two new flags (defined in section 5) that indicate: 1) this VPWS 357 service tunnel is for VLAN-aware Flexible Cross-Connect, and 2) 358 normalized VID type (single versus double). The receiving PE uses 359 these new flags for consistency check and MAY generate an alarm if it 360 detects inconsistency but doesn't bring down the VPWS service because 361 such inconsistency may be intentional - i.e., one side is configured 362 for VLAN-aware VPWS service and another side is configured for VLAN- 363 unaware VPWS service. 365 It should be noted that in this mode of operation, the PE sends a 366 single Ethernet AD route for each AC that is configured - i.e., each 367 normalized VID that is configured per ES results in generation of an 368 EVPN Ethernet AD per EVI. 370 This mode of operation provides automatic cross checking of 371 normalized VIDs used for EVPL services because these VIDs are 372 signaled in EVPN BGP. For example, if the same normalized VID is 373 configured on three PE devices (instead of two) for the same EVI, 374 then when a PE receives the second EVPN EAD per-EVI route, it 375 generates an error message unless the two EVPN EAD per-EVI routes 376 include the same ESI. Such cross-checking is not feasible in VLAN- 377 unaware FXC because the normalized VIDs are not signaled. 379 4.2.1 Local Switching 381 When cross-connection is between two ACs belonging to two multi-homed 382 Ethernet Segments on the same set of multi-homing PEs, then 383 forwarding between the two ACs MUST be performed locally during 384 normal operation (e.g., in absence of a local link failure) - i.e., 385 the traffic between the two ACs MUST be locally switched within the 386 PE. 388 In terms of control plane processing, this means that when the 389 receiving PE receives an Ethernet A-D per-EVI route whose ESI is a 390 local ESI, the PE does not alter its forwarding state based on the 391 received route. This ensures that the local switching takes 392 precedence over forwarding via MPLS/IP network. This scheme of 393 locally switched preference is consistent with baseline EVPN [RFC 394 7432] where it describes the locally switched preference for MAC/IP 395 routes. 397 In such scenarios, the Ethernet A-D per EVI route should be 398 advertised with the MPLS label either associated with the destination 399 Attachment Circuit or with the destination Ethernet Segment in order 400 to avoid any ambiguity in forwarding. In other words, the MPLS label 401 cannot represent the same VID-VRF used in section 4.2 because the 402 same normalized VID can be reachable via two Ethernet Segments. In 403 case of using MPLS label per destination AC, then this same solution 404 can be used for VLAN-based VPWS or VLAN-bundle VPWS services per 405 [RFC8214]. 407 4.3 VLAN-Unaware Flexible Xconnect - Multi-Homing 409 In this mode of operation, a group of normalized VIDs (ACs) on a 410 single Ethernet segment that are destined to a single endpoint are 411 multiplexed into a single EVPN VPWS service tunnel represented by a 412 single VPWS service ID. This mode of operation is the same as VLAN- 413 bundle service interface of [RFC8214] except for the fact that VIDs 414 on Ethernet frames are normalized before getting sent over the LSP 415 tunnel. 417 In the previous two modes of operation, only a single EVPN VPWS 418 service tunnel is needed per pair of PEs. However, in this mode of 419 operation, there can be lot more service tunnels per pair of PEs - 420 i.e, there is one tunnel per group of VIDs per pair of PEs and there 421 can be many groups between a pair of PEs, thus resulting in many EVPN 422 service tunnels. 424 < mention that awareness is wrt signaling and not VID-table !!!> 426 5. BGP Extensions 428 This draft uses the EVPN Layer-2 attribute extended community defined 429 in [RFC8214] with two additional flags added to this EC as described 430 below. This EC is to be advertised with Ethernet A-D per EVI route 431 per section 4. 433 +------------------------------------+ 434 | Type(0x06)/Sub-type(TBD)(2 octet) | 435 +------------------------------------+ 436 | Control Flags (2 octets) | 437 +------------------------------------+ 438 | L2 MTU (2 octets) | 439 +------------------------------------+ 440 | Reserved (2 octets) | 441 +------------------------------------+ 443 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | MBZ | V | M |C|P|B| (MBZ = MUST Be Zero) 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 The following bits in the Control Flags are defined; the remaining 449 bits MUST be set to zero when sending and MUST be ignored when 450 receiving this community. 452 Name Meaning 454 B,P,C per definition in [RFC8214] 456 M 00 mode of operation as defined in [RFC8214] 457 01 VLAN-aware FXC 458 10 VLAN-unaware FXC 460 V 00 operating per [RFC8214] 461 01 single-VID normalization 462 10 double-VID normalization 464 The M and V fields are OPTIONAL on transmission and ignored at 465 reception for forwarding purposes. They are used for error 466 notifications. 468 6 Failure Scenarios 470 Two examples will be used as an example to analyze the failure 471 scenarios. 473 The first scenario is depicted in Figure 1 and shows the VLAN-Aware 474 Flexible Xconnect model with Multi-Homing. In this example: 476 - CE1 is connected to PE1 and PE2 via (port,vid)=(p1,1) and (p3,3) 477 respectively. CE1's VIDs are normalized to value 1 on both PEs, and 478 CE1 is Xconnected to CE3's VID 1 at the remote end. 480 - CE2 is connected to PE1 and PE2 via ports p2 and p4 respectively: 481 o (p2,1) and (p4,3) identify the ACs that are used to Xconnect 482 CE2 to CE4's VID 2, and are normalized to value 2. 483 o (p2,2) and (p4,4) identify the ACs that are used to Xconnect 484 CE2 to CE5's VID 3, and are normalized to value 3. 486 In this scenario, PE1 and PE2 advertise an AD per-EVI route per 487 normalized VID (values 1, 2 and 3), however only two VPWS Service 488 Tunnels are needed: VPWS Service Tunnel 1 (sv.T1) between PE1's FXC 489 service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) between 490 PE2's FXC and PE3's FXC. 492 N.VID 1,2,3 +---------------------+ 493 PE1 | | 494 +---------+ IP/MPLS | 495 +-----+ VID1 p1 | +-----+ | + 496 | CE1 |------------| FXC | | sv.T1 PE3 +-----+ 497 | | /\ | | |=======+ +----------+ +--| CE3 | 498 +-----+\ +||---| | | \ | | 1/ | | 499 VID3\ / ||---| | | \ | +-----+ | / +-----+ 500 \ / /\/ | +-----+ | +=====| FXC |----+ 501 \ / p2 +---------+ | | | | 2 +-----+ 502 /\ | | |----------| CE4 | 503 / /\ +---------+ +======| | | | | 504 / / \p3 | +-----+ | / | | | | +-----+ 505 VIDs1,2 / +----| FXC | / | | |---+ 506 +-----+ / /\ | | |======+ | +-----+ |\3 +-----+ 507 | CE2 |-----||-----| | | sv.T2 | | \ | CE5 | 508 | |-----||-----| | | +----------+ +---| | 509 +-----+ \/ | +-----+ | | +-----+ 510 VIDs3,4 p4 +---------+ | 511 PE2 | | 512 N.VID 1,2,3 +------------------+ 514 Figure 1 VLAN-Aware Flexible Xconnect 516 The second scenario is a VLAN-Unaware Flexible Xconnect with Multi- 517 Homing solution and it is depicted in Figure 2. In this case, the 518 same VID Normalization as in the previous example is performed, 519 however there is not an individual AD per-EVI route per normalized 520 VID, but per bundle of ACs on an ES. That is, PE1 will advertise two 521 AD per-EVI routes: the first one will identify the ACs on p1's ES and 522 the second one will identify the AC2 in p2's ES. Similarly, PE2 will 523 advertise two AD per-EVI routes. 525 N.VID 1,2,3 +---------------------+ 526 PE1 | | 527 +---------+ IP/MPLS | 528 +-----+ VID1 p1 | +-----+ | sv.T1 + 529 | CE1 |-------------| FXC |======+ PE3 +-----+ 530 | | /\ | | | | \ +----------+ +--| CE3 | 531 +-----+\ +||---| | sv.T2 \ | | 1/ | | 532 VID3\ / ||---| |=====+ \ | +-----+ | / +-----+ 533 \ // \/ | +-----+ | \ +====| FXC |----+ 534 \ / p2 +---------+ +======| | | 2 +-----+ 535 /\ | | |----------| CE4 | 536 / /\ +---------+ +=====| | | | | 537 / / \p3 | +-----+ sv.T3 / +====| | | +-----+ 538 VIDs1,2 / +----| FXC |=======+ / | | |---+ 539 +-----+ / /\ | | | | / | +-----+ |\3 +-----+ 540 | CE2 |-----||---| | | sv.T4 / | | \ | CE5 | 541 | |-----||---| | |======+ +----------+ +---| | 542 +--VIDs3,4 \/ | +-----+ | | +-----+ 543 p4 +---------+ | 544 PE2 | | 545 N.VID 1,2,3 +-------------------+ 547 Figure 2 VLAN-Unaware Flexible Xconnect 549 6.1 EVPN VPWS service Failure 551 The failure detection of an EVPN VPWS service can be performed via 552 OAM mechanisms such as VCCV-BFD and upon such failure detection, the 553 switch over procedure to the backup S-PE is the same as the one 554 described above. 556 6.2 Attachment Circuit Failure 558 In case of AC Failure, the VLAN-Aware and VLAN-Unaware models behave 559 in a different way: 561 o VLAN-Aware (Figure 1): a VLAN or AC failure, e.g. VID1 on CE2, 562 triggers the withdrawal of the AD per-EVI route for the corresponding 563 Normalized VID, that is, Ethernet-Tag 2. When PE3 receives the route 564 withdrawal, it will remove PE1 from its path- list for traffic coming 565 from CE4. 567 o VLAN-Unaware (Figure 2): a VLAN or AC failure is not signaled in 568 the VLAN-Unaware model, therefore in case of an AC failure, e.g. VID1 569 on CE2, nothing prevents PE3 from sending CE4's traffic to PE1, 570 creating a black-hole. Application layer OAM may be used if per-VLAN 571 fault propagation is required in this case. 573 6.3 PE Port Failure 575 In case of PE port Failure, the failure will be signaled and the 576 other PE will take over in both cases: 578 o VLAN-Aware (Figure 1): a port failure, e.g. p2, triggers the 579 withdrawal of the AD per-EVI routes for Normalized VIDs 2 and 3, as 580 well as the withdrawal of the AD per-ES route for p2's ES. Upon 581 receiving the fault notification, PE3 will withdraw PE1 from its 582 path-list for the traffic coming from CE4 and CE5. 584 o VLAN-Unaware (Figure 2): a port failure, e.g. p2, is signaled by 585 route for sv.T2 will also be withdrawn. Upon receiving the fault 586 notification, PE3 will remove PE1 from its path-list for traffic 587 coming from CE4 and CE5. 589 6.4 PE Node Failure 591 In the case of PE node failure, the operation is similar to the steps 592 described above, albeit that EVPN route withdrawals are performed by 593 the Route Reflector instead of the PE. 595 7 Security Considerations 597 There are no additional security considerations beyond what is 598 already specified in [RFC8214]. 600 8 IANA Considerations 602 TBD. 604 9 References 606 9.1 Normative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 [RFC7432] Sajassi et al., "Ethernet VPN", RFC 7432, February 2015. 613 [RFC8214] Boutros et al., "Virtual Private Wire Service Support in 614 Ethernet VPN", RFC 8214, August 2015. 616 9.2 Informative References 618 [BGP-PIC] Bashandy A. et al., "BGP Prefix Independent Convergence", 619 draft-rtgwg-bgp-pic-02.txt, work in progress, October 620 2013. 622 [EVPN-Overlay] Sajassi et al., "A Network Virtualization Overlay 623 Solution using EVPN", draft-ietf-bess-evpn-overlay-12, 624 work in progress, February 2018. 626 Authors' Addresses 628 A. Sajassi 629 Cisco 630 EMail: sajassi@cisco.com 632 P. Brissette 633 Cisco 634 EMail: pbrisset@cisco.com 636 J. Uttaro 637 ATT 638 EMail: ju1738@att.com 640 J. Drake 641 Juniper 642 EMail: jdrake@juniper.net 644 S. Boutros 645 ATT 646 EMail: boutros.sami@gmail.com 647 W. Lin 648 Juniper 649 EMail: wlin@juniper.net 651 J. Rabadan 652 jorge.rabadan@nokia.com