idnits 2.17.1 draft-ietf-bess-evpn-vpws-fxc-01.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 (June 6, 2019) is 1776 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: December 6, 2019 June 6, 2019 17 EVPN VPWS Flexible Cross-Connect Service 18 draft-ietf-bess-evpn-vpws-fxc-01.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 Flexible Xconnect . . . . . . . . . . . . . . . . . . . . . 7 72 4.2 VLAN-Signaled Flexible Xconnect . . . . . . . . . . . . . . 8 73 4.2.1 Local Switching . . . . . . . . . . . . . . . . . . . . 9 74 5. BGP Extensions . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6 Failure Scenarios . . . . . . . . . . . . . . . . . . . . . . . 11 76 6.1 EVPN VPWS service Failure . . . . . . . . . . . . . . . . . 13 77 6.2 Attachment Circuit Failure . . . . . . . . . . . . . . . . . 13 78 6.3 PE Port Failure . . . . . . . . . . . . . . . . . . . . . . 14 79 6.4 PE Node Failure . . . . . . . . . . . . . . . . . . . . . . 14 80 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 81 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 82 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 84 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 1 Introduction 89 [RFC8214] describes a solution to deliver P2P services using BGP 90 constructs defined in [RFC7432]. It delivers this P2P service between 91 a pair of Attachment Circuits (ACs), where an AC can designate on a 92 PE, a port, a VLAN on a port, or a group of VLANs on a port. It also 93 leverages multi-homing and fast convergence capabilities of [RFC7432] 94 in delivering these VPWS services. Multi-homing capabilities include 95 the support of single-active and all-active redundancy mode and fast 96 convergence is provided using "mass withdraw" message in control- 97 plane and fast protection switching using prefix independent 98 convergence in data-plane upon node or link failure [BGP-PIC]. 99 Furthermore, the use of EVPN BGP constructs eliminates the need for 100 multi-segment PW auto-discovery and signaling if the VPWS service 101 need to span across multiple ASes. 103 Some service providers have very large number of ACs (in millions) 104 that need to be back hauled across their MPLS/IP network. These ACs 105 may or may not require tag manipulation (e.g., VLAN translation). 106 These service providers want to multiplex a large number of ACs 107 across several physical interfaces spread across one or more PEs 108 (e.g., several Ethernet Segments) onto a single VPWS service tunnel 109 in order to a) reduce number of EVPN service labels associated with 110 EVPN-VPWS service tunnels and thus the associated OAM monitoring, and 111 b) reduce EVPN BGP signaling (e.g., not to signal each AC as it is 112 the case in [RFC8214]). 114 These service provider want the above functionality without 115 scarifying any of the capabilities of [RFC8214] including single- 116 active and all-active multi-homing, and fast convergence. 118 This document presents a solution based on extensions to [RFC8214] to 119 meet the above requirements. 121 1.1 Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119 [RFC2119]. 127 MAC: Media Access Control 129 MPLS: Multi Protocol Label Switching 131 OAM: Operations, Administration and Maintenance 133 PE: Provide Edge Node 134 CE: Customer Edge device e.g., host or router or switch 136 EVPL: Ethernet Virtual Private Line 138 EPL: Ethernet Private Line 140 ES: Ethernet Segment 142 VPWS: Virtual private wire service 144 EVI: EVPN Instance 146 VPWS Service Tunnel: It is represented by a pair of EVPN service 147 labels associated with a pair of endpoints. Each label is downstream 148 assigned and advertised by the disposition PE through an Ethernet A-D 149 per-EVI route. The downstream label identifies the endpoint on the 150 disposition PE. A VPWS service tunnel can be associated with many 151 VPWS service identifiers for VLAN-signaled VPWS service where each 152 identifier is a normalized VID. 154 Single-Active Mode: When a device or a network is multi-homed to two 155 or more PEs and when only a single PE in such redundancy group can 156 forward traffic to/from the multi-homed device or network for a given 157 VLAN, then such multi-homing or redundancy is referred to as "Single- 158 Active". 160 All-Active: When a device is multi-homed to two or more PEs and when 161 all PEs in such redundancy group can forward traffic to/from the 162 multi-homed device for a given VLAN, then such multi-homing or 163 redundancy is referred to as "All-Active". 165 2 Requirements 167 Two of the main motivations for service providers seeking a new 168 solution are: 1) to reduce number of VPWS service tunnels by 169 multiplexing large number of ACs across different physical interfaces 170 instead of having one VPWS service tunnel per AC, and 2) to reduce 171 the signaling of ACs as much as possible. Besides these two 172 requirements, they also want multi-homing and fast convergence 173 capabilities of [RFC8214]. 175 In [RFC8214], a PE signals an AC indirectly by first associating that 176 AC to a VPWS service tunnel (e.g., a VPWS service instance) and then 177 signaling the VPWS service tunnel via a per-EVI Ethernet AD route 178 with Ethernet Tag field set to a 24-bit VPWS service instance 179 identifier (which is unique within the EVI) and ESI field set to a 180 10-octet identifier of the Ethernet Segment corresponding to that AC. 182 Therefore, a PE device that receives such EVPN routes, can associate 183 the VPWS service tunnel to the remote Ethernet Segment, and when the 184 remote ES fails and the PE receives the "mass withdraw" message 185 associated with the failed ES per [RFC7432], it can update its BGP 186 path list for that VPWS service tunnel quickly and achieve fast 187 convergence for multi-homing scenarios. Even if fast convergence were 188 not needed, there would still be a need for signaling each AC failure 189 (via its corresponding VPWS service tunnel) associated with the 190 failed ES, so that the BGP path list for each of them gets updated 191 accordingly and the packets are sent to backup PE (in case of single- 192 active multi-homing) or to other PEs in the redundancy group (in case 193 of all-active multi-homing). In absence of updating the BGP path 194 list, the traffic for that VPWS service tunnel will be black-holed. 196 When a single VPWS service tunnel multiplexes many ACs across number 197 of Ethernet Segments (number of physical interfaces) and the ACs are 198 not signaled via EVPN BGP to remote PE devices, then the remote PE 199 devices neither know the association of the received Ethernet Segment 200 to these ACs (and in turn to their local ACs) nor they know the 201 association of the VPWS service tunnel (e.g., EVPN service label) to 202 the far-end ACs - i.e, the remote PEs only know the association of 203 their local ACs to the VPWS service tunnel but not the far-end ACs. 204 Thus upon a connectivity failure to the ES, they don't know how to 205 redirect traffic via another multi-homing PE to that ES. In other 206 words, even if an ES failure is signaled via EVPN to the remote PE 207 devices, they don't know what to do with such message because they 208 don't know the association among the remote ES, the remote ACs, and 209 the VPWS service tunnel. 211 In order to address this issue when multiplexing large number of ACs 212 onto a single VPWS service tunnel, two mechanisms are devised: one to 213 support VPWS services between two single-homed endpoints and another 214 one to support VPWS services where one of the endpoints is multi- 215 homed. An endpoint can be an AC, MAC-VRF, IP-VRF, global table, or 216 etc. 218 For single-homed endpoints, it is OK not to signal each AC in BGP 219 because upon connection failure to the ES, there is no alternative 220 path to that endpoint. However, the ramification for not signaling an 221 AC failure is that the traffic destined to the failed AC, is sent 222 over MPLS/IP core and then gets discarded at the destination PE - 223 i.e., it can waste network resources. However, when there is a 224 connection failure, the application layer will eventually stop 225 sending traffic and thus this wastage of network resources should be 226 transient. Section 4.1 describes a solution for such single-homing 227 VPWS service. 229 For VPWS services where one of the endpoints is multi-homed, there 230 are two options: 232 1) to signal each AC via BGP so that the path list can be updated 233 upon a failure that impacts those ACs. This solution is described in 234 section 4.2 and it is called VLAN-signaled flexible cross-connect 235 service. 237 2) to bundle several ACs on an ES together per destination end-point 238 (e.g., ES, MAC-VRF, etc.) and associated such bundle to a single VPWS 239 service tunnel. This is similar to VLAN-bundle service interface 240 described in [RFC8214]. This solution is described in section 4.3. 242 4 Solution 244 This section describes a solution for providing a new VPWS service 245 between two PE devices where a large number of ACs (e.g., VLANs) that 246 span across many Ethernet Segments (i.e., physical interfaces) on 247 each PE are multiplex onto a single P2P EVPN service tunnel. Since 248 multiplexing is done across several physical interfaces, there can be 249 overlapping VLAN IDs across these interfaces; therefore, in such 250 scenarios, the VLAN IDs (VIDs) MUST be translated into unique VIDs to 251 avoid collision. Furthermore, if the number of VLANs that are getting 252 multiplex onto a single VPWS service tunnel, exceed 4K, then a single 253 tag to double tag translation MUST be performed. This translation of 254 VIDs into unique VIDs (either single or double) is referred to as 255 "VID normalization". When single normalized VID is used, the lower 256 12-bit of Ethernet tag field in EVPN routes is set to that VID and 257 when double normalized VID is used, the lower 12-bit of Ethernet tag 258 field is set to inner VID and the higher 12-bit is set to the outer 259 VID. 261 Since there is only a single EVPN VPWS service tunnel associated with 262 many normalized VIDs (either single or double) across multiple 263 physical interfaces, MPLS lookup at the disposition PE is no longer 264 sufficient to forward the packet to the right egress 265 endpoint/interface. Therefore, in addition to an EVPN label lookup 266 corresponding to the VPWS service tunnel, a VID lookup (either single 267 or double) is also required. On the disposition PE, one can think of 268 the lookup of EVPN label results in identification of a VID-VRF, and 269 the lookup of normalized VID(s) in that table, results in 270 identification of egress endpoint/interface. The tag manipulation 271 (translation from normalized VID(s) to local VID) can be performed 272 either as part of the VID table lookup or at the egress interface 273 itself. 275 Since VID lookup (single or double) needs to be performed at the 276 disposition PE, then VID normalization MUST be performed prior to the 277 MPLS encapsulation on the ingress PE. This requires that both 278 imposition and disposition PE devices be capable of VLAN tag 279 manipulation, such as re-write (single or double), addition, deletion 280 (single or double) at their endpoints (e.g., their ES's, MAC-VRFs, 281 IP-VRFs, etc.). 283 4.1 Flexible Xconnect 285 In this mode of operation, many ACs across several Ethernet Segments 286 are multiplex into a single EVPN VPWS service tunnel represented by a 287 single VPWS service ID. This is the default mode of operation for FXC 288 and the participating PEs do not need to signal the VLANs (normalized 289 VIDs) in EVPN BGP. 291 With respect to the data-plane aspects of the solution, both 292 imposition and disposition PEs are aware of the VLANs as the 293 imposition PE performs VID normalization and the disposition PE does 294 VID lookup and translation. In this solution, there is only a single 295 P2P EVPN VPWS service tunnel between a pair of PEs for a set of ACs. 297 As discussed previously, since the EVPN VPWS service tunnel is used 298 to multiplex ACs across different ES's (e.g., physical interfaces), 299 the EVPN label alone is not sufficient for proper forwarding of the 300 received packets (over MPLS/IP network) to egress interfaces. 301 Therefore, normalized VID lookup is required in the disposition 302 direction to forward packets to their proper egress end-points - 303 i.e., the EVPN label lookup identifies a VID-VRF and subsequently, 304 the normalized VID lookup in that table, identifies the egress 305 interface. 307 This mode of operation is only suitable for single-homing because in 308 multi-homing the association between EVPN VPWS service tunnel and 309 remote AC changes during the failure and therefore the VLANs 310 (normalized VIDs) need to be signaled. 312 In this solution, on each PE, the single-homing ACs represented by 313 their normalized VIDs are associated with a single EVPN VPWS service 314 tunnel (in a given EVI). The EVPN route that gets generated is an 315 EVPN Ethernet AD per EVI route with ESI=0, Ethernet Tag field set to 316 VPWS service instance ID, MPLS label field set to dynamically 317 generated EVPN service label representing the EVPN VPWS service 318 tunnel. This route is sent with an RT representing the EVI. This RT 319 can be auto-generated from the EVI per section 5.1.2.1 of [EVPN- 320 Overlay]. Furthermore, this route is sent with the EVPN Layer-2 321 Extended Community defined in section 3.1 of [RFC8214] with two new 322 flags (defined in section 5) that indicate: 1) this VPWS service 323 tunnel is for default Flexible Cross-Connect, and 2) normalized VID 324 type (single versus double). The receiving PE uses these new flags 325 for consistency check and MAY generate an alarm if it detects 326 inconsistency but doesn't bring down the VPWS service. 328 It should be noted that in this mode of operation, a single Ethernet 329 AD per EVI route is sent upon configuration of the first AC (ie, 330 normalized VID). Later, when additional ACs are configured and 331 associated with this EVPN VPWS service tunnel, the PE does not 332 advertise any additional EVPN BGP routes. The PE only associates 333 locally these ACs with the already created VPWS service tunnel. 335 The default FXC mode can be used for multi-homing. In this mode, a 336 group of normalized VIDs (ACs) on a single Ethernet segment that are 337 destined to a single endpoint are multiplexed into a single EVPN VPWS 338 service tunnel represented by a single VPWS service ID. When the 339 default FXC mode is used for multi-homing, instead of a single EVPN 340 VPWS service tunnel, there can be many service tunnels per pair of 341 PEs - i.e, there is one tunnel per group of VIDs per pair of PEs and 342 there can be many groups between a pair of PEs, thus resulting in 343 many EVPN service tunnels. 345 4.2 VLAN-Signaled Flexible Xconnect 347 In this mode of operation, just as the default FXC mode in section 348 4.1, many normalized VIDs (ACs) across several different 349 ES's/interfaces are multiplexed into a single EVPN VPWS service 350 tunnel; however, this single tunnel is represented by many VPWS 351 service IDs (one per normalized VID) and these normalized VIDs are 352 signaled using EVPN BGP. 354 In this solution, on each PE, the multi-homing ACs represented by 355 their normalized VIDs are configured with a single EVI. There is no 356 need to configure VPWS service instance ID in here as it is the same 357 as the normalized VID. For each normalized VID on each ES, the PE 358 generates an EVPN Ethernet AD per EVI route where ESI field 359 represents the ES ID, the Ethernet Tag field is set to the normalized 360 VID, MPLS label field is set to dynamically generated EVPN label 361 representing the P2P EVPN service tunnel and it is the same label for 362 all the ACs that are multiplexed into a single EVPN VPWS service 363 tunnel. This route is sent with an RT representing the EVI. As 364 before, this RT can be auto-generated from the EVI per section 365 5.1.2.1 of [EVPN-Overlay]. Furthermore, this route is sent with the 366 EVPN Layer-2 Extended Community defined in section 3.1 of [RFC8214] 367 with two new flags (defined in section 5) that indicate: 1) this VPWS 368 service tunnel is for VLAN-signaled Flexible Cross-Connect, and 2) 369 normalized VID type (single versus double). The receiving PE uses 370 these new flags for consistency check and MAY generate an alarm if it 371 detects inconsistency but doesn't bring down the VPWS service. 373 It should be noted that in this mode of operation, the PE sends a 374 single Ethernet AD route for each AC that is configured - i.e., each 375 normalized VID that is configured per ES results in generation of an 376 EVPN Ethernet AD per EVI. 378 This mode of operation provides automatic cross checking of 379 normalized VIDs used for EVPL services because these VIDs are 380 signaled in EVPN BGP. For example, if the same normalized VID is 381 configured on three PE devices (instead of two) for the same EVI, 382 then when a PE receives the second EVPN EAD per-EVI route, it 383 generates an error message unless the two EVPN EAD per-EVI routes 384 include the same ESI. Such cross-checking is not feasible in default 385 FXC mode because the normalized VIDs are not signaled. 387 4.2.1 Local Switching 389 When cross-connection is between two ACs belonging to two multi-homed 390 Ethernet Segments on the same set of multi-homing PEs, then 391 forwarding between the two ACs MUST be performed locally during 392 normal operation (e.g., in absence of a local link failure) - i.e., 393 the traffic between the two ACs MUST be locally switched within the 394 PE. 396 In terms of control plane processing, this means that when the 397 receiving PE receives an Ethernet A-D per-EVI route whose ESI is a 398 local ESI, the PE does not alter its forwarding state based on the 399 received route. This ensures that the local switching takes 400 precedence over forwarding via MPLS/IP network. This scheme of 401 locally switched preference is consistent with baseline EVPN [RFC 402 7432] where it describes the locally switched preference for MAC/IP 403 routes. 405 In such scenarios, the Ethernet A-D per EVI route should be 406 advertised with the MPLS label either associated with the destination 407 Attachment Circuit or with the destination Ethernet Segment in order 408 to avoid any ambiguity in forwarding. In other words, the MPLS label 409 cannot represent the same VID-VRF used in section 4.2 because the 410 same normalized VID can be reachable via two Ethernet Segments. In 411 case of using MPLS label per destination AC, then this same solution 412 can be used for VLAN-based VPWS or VLAN-bundle VPWS services per 413 [RFC8214]. 415 5. BGP Extensions 416 This draft uses the EVPN Layer-2 attribute extended community defined 417 in [RFC8214] with two additional flags added to this EC as described 418 below. This EC is to be advertised with Ethernet A-D per EVI route 419 per section 4. 421 +------------------------------------+ 422 | Type(0x06)/Sub-type(TBD)(2 octet) | 423 +------------------------------------+ 424 | Control Flags (2 octets) | 425 +------------------------------------+ 426 | L2 MTU (2 octets) | 427 +------------------------------------+ 428 | Reserved (2 octets) | 429 +------------------------------------+ 431 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | MBZ | V | M |C|P|B| (MBZ = MUST Be Zero) 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 The following bits in the Control Flags are defined; the remaining 437 bits MUST be set to zero when sending and MUST be ignored when 438 receiving this community. 440 Name Meaning 442 B,P,C per definition in [RFC8214] 444 M 00 mode of operation as defined in [RFC8214] 445 01 VLAN-Signaled FXC 446 10 Default FXC 448 V 00 operating per [RFC8214] 449 01 single-VID normalization 450 10 double-VID normalization 452 The M and V fields are OPTIONAL on transmission and ignored at 453 reception for forwarding purposes. They are used for error 454 notifications. 456 6 Failure Scenarios 458 Two examples will be used as an example to analyze the failure 459 scenarios. 461 The first scenario is depicted in Figure 1 and shows the VLAN- 462 signaled FXC mode with Multi-Homing. In this example: 464 - CE1 is connected to PE1 and PE2 via (port,vid)=(p1,1) and (p3,3) 465 respectively. CE1's VIDs are normalized to value 1 on both PEs, and 466 CE1 is Xconnected to CE3's VID 1 at the remote end. 468 - CE2 is connected to PE1 and PE2 via ports p2 and p4 respectively: 469 o (p2,1) and (p4,3) identify the ACs that are used to Xconnect 470 CE2 to CE4's VID 2, and are normalized to value 2. 471 o (p2,2) and (p4,4) identify the ACs that are used to Xconnect 472 CE2 to CE5's VID 3, and are normalized to value 3. 474 In this scenario, PE1 and PE2 advertise an AD per-EVI route per 475 normalized VID (values 1, 2 and 3), however only two VPWS Service 476 Tunnels are needed: VPWS Service Tunnel 1 (sv.T1) between PE1's FXC 477 service and PE3's FXC, and VPWS Service Tunnel 2 (sv.T2) between 478 PE2's FXC and PE3's FXC. 480 N.VID 1,2,3 +---------------------+ 481 PE1 | | 482 +---------+ IP/MPLS | 483 +-----+ VID1 p1 | +-----+ | + 484 | CE1 |------------| FXC | | sv.T1 PE3 +-----+ 485 | | /\ | | |=======+ +----------+ +--| CE3 | 486 +-----+\ +||---| | | \ | | 1/ | | 487 VID3\ / ||---| | | \ | +-----+ | / +-----+ 488 \ / /\/ | +-----+ | +=====| FXC |----+ 489 \ / p2 +---------+ | | | | 2 +-----+ 490 /\ | | |----------| CE4 | 491 / /\ +---------+ +======| | | | | 492 / / \p3 | +-----+ | / | | | | +-----+ 493 VIDs1,2 / +----| FXC | / | | |---+ 494 +-----+ / /\ | | |======+ | +-----+ |\3 +-----+ 495 | CE2 |-----||-----| | | sv.T2 | | \ | CE5 | 496 | |-----||-----| | | +----------+ +---| | 497 +-----+ \/ | +-----+ | | +-----+ 498 VIDs3,4 p4 +---------+ | 499 PE2 | | 500 N.VID 1,2,3 +------------------+ 502 Figure 1 VLAN-Signaled Flexible Xconnect 504 The second scenario is a default Flexible Xconnect with Multi- Homing 505 solution and it is depicted in Figure 2. In this case, the same VID 506 Normalization as in the previous example is performed, however there 507 is not an individual AD per-EVI route per normalized VID, but per 508 bundle of ACs on an ES. That is, PE1 will advertise two AD per-EVI 509 routes: the first one will identify the ACs on p1's ES and the second 510 one will identify the AC2 in p2's ES. Similarly, PE2 will advertise 511 two AD per-EVI routes. 513 N.VID 1,2,3 +---------------------+ 514 PE1 | | 515 +---------+ IP/MPLS | 516 +-----+ VID1 p1 | +-----+ | sv.T1 + 517 | CE1 |-------------| FXC |======+ PE3 +-----+ 518 | | /\ | | | | \ +----------+ +--| CE3 | 519 +-----+\ +||---| | sv.T2 \ | | 1/ | | 520 VID3\ / ||---| |=====+ \ | +-----+ | / +-----+ 521 \ // \/ | +-----+ | \ +====| FXC |----+ 522 \ / p2 +---------+ +======| | | 2 +-----+ 523 /\ | | |----------| CE4 | 524 / /\ +---------+ +=====| | | | | 525 / / \p3 | +-----+ sv.T3 / +====| | | +-----+ 526 VIDs1,2 / +----| FXC |=======+ / | | |---+ 527 +-----+ / /\ | | | | / | +-----+ |\3 +-----+ 528 | CE2 |-----||---| | | sv.T4 / | | \ | CE5 | 529 | |-----||---| | |======+ +----------+ +---| | 530 +--VIDs3,4 \/ | +-----+ | | +-----+ 531 p4 +---------+ | 532 PE2 | | 533 N.VID 1,2,3 +-------------------+ 535 Figure 2 Default Flexible Xconnect 537 6.1 EVPN VPWS service Failure 539 The failure detection of an EVPN VPWS service can be performed via 540 OAM mechanisms such as VCCV-BFD and upon such failure detection, the 541 switch over procedure to the backup S-PE is the same as the one 542 described above. 544 6.2 Attachment Circuit Failure 546 In case of AC Failure, the VLAN-Signaled and default FXC modes behave 547 in a different way: 549 o VLAN-signaled FXC (Figure 1): a VLAN or AC failure, e.g. VID1 on 550 CE2, triggers the withdrawal of the AD per-EVI route for the 551 corresponding Normalized VID, that is, Ethernet-Tag 2. When PE3 552 receives the route withdrawal, it will remove PE1 from its path- list 553 for traffic coming from CE4. 555 o Default FXC (Figure 2): a VLAN or AC failure is not signaled in the 556 default mode, therefore in case of an AC failure, e.g. VID1 on CE2, 557 nothing prevents PE3 from sending CE4's traffic to PE1, creating a 558 black-hole. Application layer OAM may be used if per-VLAN fault 559 propagation is required in this case. 561 6.3 PE Port Failure 563 In case of PE port Failure, the failure will be signaled and the 564 other PE will take over in both cases: 566 o VLAN-signaled FXC (Figure 1): a port failure, e.g. p2, triggers the 567 withdrawal of the AD per-EVI routes for Normalized VIDs 2 and 3, as 568 well as the withdrawal of the AD per-ES route for p2's ES. Upon 569 receiving the fault notification, PE3 will withdraw PE1 from its 570 path-list for the traffic coming from CE4 and CE5. 572 o Default FXC (Figure 2): a port failure, e.g. p2, is signaled by 573 route for sv.T2 will also be withdrawn. Upon receiving the fault 574 notification, PE3 will remove PE1 from its path-list for traffic 575 coming from CE4 and CE5. 577 6.4 PE Node Failure 579 In the case of PE node failure, the operation is similar to the steps 580 described above, albeit that EVPN route withdrawals are performed by 581 the Route Reflector instead of the PE. 583 7 Security Considerations 585 There are no additional security considerations beyond what is 586 already specified in [RFC8214]. 588 8 IANA Considerations 590 TBD. 592 9 References 594 9.1 Normative References 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC7432] Sajassi et al., "Ethernet VPN", RFC 7432, February 2015. 601 [RFC8214] Boutros et al., "Virtual Private Wire Service Support in 602 Ethernet VPN", RFC 8214, August 2015. 604 9.2 Informative References 606 [BGP-PIC] Bashandy A. et al., "BGP Prefix Independent Convergence", 607 draft-rtgwg-bgp-pic-02.txt, work in progress, October 608 2013. 610 [EVPN-Overlay] Sajassi et al., "A Network Virtualization Overlay 611 Solution using EVPN", draft-ietf-bess-evpn-overlay-12, 612 work in progress, February 2018. 614 Authors' Addresses 616 A. Sajassi 617 Cisco 618 EMail: sajassi@cisco.com 620 P. Brissette 621 Cisco 622 EMail: pbrisset@cisco.com 624 J. Uttaro 625 ATT 626 EMail: ju1738@att.com 628 J. Drake 629 Juniper 630 EMail: jdrake@juniper.net 632 S. Boutros 633 ATT 634 EMail: boutros.sami@gmail.com 635 W. Lin 636 Juniper 637 EMail: wlin@juniper.net 639 J. Rabadan 640 jorge.rabadan@nokia.com