idnits 2.17.1 draft-lin-bess-evpn-bgp-based-l2vpn-seamless-integ-00.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 (November 1, 2019) is 1638 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) ** Downref: Normative reference to an Informational RFC: RFC 6624 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS W. Lin 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track B. Wen 5 Expires: May 4, 2020 V. Kozak 6 Comcast 7 J. Rabadan 8 Nokia 9 November 1, 2019 11 EVPN and BGP-based L2VPN Seamless Integration 12 draft-lin-bess-evpn-bgp-based-l2vpn-seamless-integ-00 14 Abstract 16 This document presents a seamless integration solution for BGP-based 17 Layer-2 VPN (L2VPN) and EVPN to provide point-to-point Virtual 18 Private Wire Service (VPWS). In addition, this document also extends 19 the existing seamless integration for multipoint Ethernet VPN service 20 with all-active multihoming support. The specified solution allows 21 the coexistence of EVPN and L2VPN services under the same point-to- 22 point or multipoint VPN instance. By using this seamless integration 23 solution, a service provider can introduce EVPN into their existing 24 L2VPN network or migrate from an existing L2VPN based network to 25 EVPN. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119] [RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on May 4, 2020. 51 Copyright Notice 53 Copyright (c) 2019 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. L2VPN PE, EVPN PE and Composite PE . . . . . . . . . . . . . 5 71 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5. Model of Operation for Seamless Integration of Point-to-point 73 Ethernet VPN . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.1. Point-to-point Ethernet VPN . . . . . . . . . . . . . . . 6 75 5.2. Operation Model for Seamless Integration . . . . . . . . 7 76 5.3. Seamless Integration for Single Homing or Multihoming . . 7 77 5.4. Control Plane Overview . . . . . . . . . . . . . . . . . 8 78 5.5. Data Plane Overview . . . . . . . . . . . . . . . . . . . 8 79 6. Seamless Integration Solution for Point-to-point Ethernet VPN 8 80 6.1. Local ID and Remote ID . . . . . . . . . . . . . . . . . 9 81 6.2. Composite PE Control Plane Procedure . . . . . . . . . . 9 82 6.2.1. Auto-Discovery . . . . . . . . . . . . . . . . . . . 9 83 6.2.2. Control Plane Signaling . . . . . . . . . . . . . . . 10 84 6.2.3. Status of an Attachment Circuit . . . . . . . . . . . 11 85 6.2.4. Layer 2 Extended Community . . . . . . . . . . . . . 11 86 6.2.5. Port-active Multihoming and DF election . . . . . . . 12 87 6.2.6. Optimization . . . . . . . . . . . . . . . . . . . . 12 88 6.3. Composite PE Forwarding Procedure . . . . . . . . . . . . 13 89 6.4. Composite PE Procedures for All-Active Multi-Homing . . . 15 90 7. Extended Seamless Integration Solution for Multipoint 91 Ethernet VPN . . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.1. All-Active Multi-Homing and Seamless Integration for BGP- 93 VPLS services . . . . . . . . . . . . . . . . . . . . . . 16 94 7.2. Extensions for MAC Flush . . . . . . . . . . . . . . . . 18 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 98 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 101 12.2. Informative References . . . . . . . . . . . . . . . . . 20 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 104 1. Introduction 106 [RFC6624] specifies a point-to-point L2VPN solution by using BGP 107 auto-discovery and signaling. This BGP-based L2VPN service may offer 108 point-to-point service using different types of L2 encapsulation, 109 such as Ethernet, frame relay, etc., and with single home or active- 110 standby redundancy. 112 EVPN VPWS leverages the latest EVPN technology and brings extra 113 functions to Layer 2 point-to-point Ethernet service, such as all- 114 active redundancy, load balancing and mass withdrawal. All-active 115 redundancy also makes it easier to achieve fast convergence on an 116 access link or node failure. 118 When expanding an existing L2VPN network with Ethernet encapsulation, 119 service provider may want to deploy EVPN VPWS to provide additional 120 Layer 2 point to point Ethernet services, and at the same time some 121 of the customer traffic may still need to be terminated on the 122 existing L2VPN PEs within the service provider network. 124 This document describes a seamless-integration solution that allows 125 the co-existence of point-to-point Ethernet services using BGP-based 126 L2VPN procedure per [RFC6624] or EVPN VPWS procedure per [RFC8214] 127 under the same VPN network and over the same MPLS/IP network. 128 Service providers may also use the seamless integration solution for 129 migration a traditional L2VPN network to EVPN VPWS based network. 131 For the multipoint Ethernet VPN service, [RFC8560] specifies a 132 seamless integration solution for VPLS and EVPN with single home and 133 single-active redundancy support. This document extends the seamless 134 integration solution defined in [RFC8560] with all-active multihoming 135 support for PEs that can support both VPLS per [RFC4761] and EVPN 136 procedures. In the extended solution, VPLS [RFC4761] procedure is 137 used to establish PWs to the rest of VPLS PEs in the same VPN 138 network. Support for using VPLS [RFC4762] procedure to set up PWs to 139 the rest of VPLS PEs is outside the scope of this document. 141 In this document, section 5 and 6 describe the requirements and 142 operation model for the seamless integration solution for point-to- 143 point Ethernet VPN. Section 6 covers the solution and procedure in 144 more detail. 146 The extended seamless integration solution for multipoint Ethernet 147 VPN is covered in Section 7. 149 2. Terminology 151 AC: Attachment Circuit. In EVPN VPWS, an attachment circuit for EVPN 152 is also referred to as an Ethernet Segment (ES). 154 L2: Layer 2 156 VPWS: Virtual Private Wire Service 158 Point to point: P2P 160 P2P Ethernet Service: a point-to-point L2 service where the hand-off 161 between a Provide Edge (PE) and a Customer Edge (CE) is based on L2 162 Ethernet. In this document a P2P Ethernet service is established 163 based on control plane procedure specified in this document or EVPN 164 VPWS [RFC8214] or BGP based L2VPN [RFC6624]. Forwarding is based on 165 using an MPLS label as the demultiplexer. 167 L2VPN PE: a PE supports L2VPN services based on the procedures 168 specified in [RFC6624] 170 EVPN VPWS PE: a PE supports EVPN VPWS based on the procedures 171 specified in [RFC8214]. In this document an EVPN VPWS PE may also be 172 referred to as an EVPN PE for short. An EVPN PE may or may not 173 support seamless integration solution specified in this document. 175 BGP VPLS PE: a PE supports VPLS procedure and multipoint Ethernet VPN 176 service defined in [RFC4761]. 178 Composite PE: In the context of a point-to-point Ethernet VPN, a 179 composite PE is a PE that can provide seamless integration solution 180 specified in this document based on both L2VPN procedure per 181 [RFC6624] and EVPN VPWS procedure per [RFC8214] under the same VPN 182 instance. In the context of a multipoint Ethernet VPN, a composite 183 PE is a PE that can provide seamless integration solution based on 184 [RFC8560] as well as the extended procedure specified in this 185 document under section 7. 187 L2VPN Route: a BGP NLRI used for auto-discovery and signaling for 188 L2VPN per [RFC6624]. [RFC6624], in turns, uses BGP VPLS NRLI defined 189 in [RFC4761] for L2VPN. Through out this document, the terms "L2VPN 190 A-D route" and "L2VN route" are used exchangeable. 192 BGP-VPLS route: a BGP NLRI used for auto-discovery and signaling for 193 BGP-based VPLS per [RFC4761]. 195 EVPN E-AD per EVI Route: an EVPN Ethernet A-D per EVI route used for 196 auto-discovery and signaling for EVPN VPWS per [RFC8214]. 198 This document does not distinguish between "all-active" and "active- 199 active" and they are used interchangeably. The same applies to 200 "single-active" and "active-standby". 202 This document also uses the terms "P2P Ethernet service" and "VPWS" 203 interchangeably. For simplicity, this document may refer to a P2P 204 Ethernet service as a P2P service for short. 206 This document also makes frequent use of the terminologies specified 207 in [RFC4761], [RFC6624], [RFC7432] and [RFC8214] 209 3. L2VPN PE, EVPN PE and Composite PE 211 There are three types of PEs defined in this seamless integration 212 solution: L2VPN PE, EVPN PE and composite PE. Under a given Layer 2 213 Ethernet VPN, the type of PE is categorized by the technology it is 214 provisioned for. For instance, a PE that is provisioned to use L2VPN 215 and EVPN on the same VPN service is considered a composite PE. A 216 L2VPN PE that provides BGP-VPLS service per [RFC4761] is also 217 referred to as BGP-VPLS or VPLS PE for short. 219 Also in this document in the context of a given Layer 2 Ethernet VPN, 220 an EVPN PE is a PE that is provisioned to provide only the EVPN 221 solution per [RFC8214], or [RFC7432] or both, but not seamless 222 integration solution. It is irrelevant whether an EVPN PE is capable 223 to support seamless integration solution. 225 For example, for a non-L2VPN PE, a network administrator may know 226 a-priori that the PE does not need to establish any P2P Ethernet 227 service that involves L2VPN PE under a given Layer 2 Ethernet VPN 228 instance. In this case, the PE can be provisioned to act only as an 229 EVPN PE for that VPN even though it is capable of providing seamless 230 integration procedure. If such a prior knowledge is unavailable, 231 then a PE SHALL be provisioned to act as a composite PE if it is 232 capable of. Otherwise, it is unable to establish a P2P Ethernet 233 service with a L2VPN PE. 235 The term "homogeneous PEs" refers to PEs that are of the same types. 236 Unless explicitly specified in this specification, a PE's type 237 applies to a given Layer 2 Ethernet VPN instance. A PE may act as an 238 EVPN PE for one VPN, but as a composite PE for another VPN. 240 4. Requirements 242 The seamless integration solution for point-to-point Ethernet VPN 243 meets the following requirements: 245 o It must allow L2VPN, EVPN and composite PEs to participate in the 246 same Layer 2 Ethernet VPN instance. 248 o The composite PE, the PE that supports the seamless integration 249 solution, must be backward compatible to support both EVPN VPWS 250 and L2VPN when Ethernet is used as the hand-off between the PE and 251 CE. The composite PE must support the establishment of a layer 2 252 P2P Ethernet service with a L2VPN PE or an EVPN PE. 254 o No change should be required for any exiting L2VPN PEs beyond what 255 are already specified in [RFC6624]. 257 o The seamless integration solution must support a CE single homed 258 to PEs of different types: L2VPN, EVPN and composite PEs. 260 o The seamless solution must support active-standby, also known as 261 single-active, redundancy for L2VPN PEs or EVPN PEs or composite 262 PEs, as long as PEs connecting to the same multihomed CE are of 263 the same type. 265 o Composite PEs provisioned for all-active multihoming for their 266 multithemed CE(s) MUST work with L2VPN PE(s) working in single 267 home or active-standby multihoming. 269 o The solution SHALL support control word forwarding procedure 270 defined in [RFC4448]. 272 o The solution SHALL support staged migration to EVPN VPWS network 273 when all L2VPN PEs are upgraded to support EVPN VPWS. 275 The requirements for the seamless integration solution for multipoint 276 Ethernet VPN are specified in [RFC8560] and they are also reiterated 277 in section 7. 279 5. Model of Operation for Seamless Integration of Point-to-point 280 Ethernet VPN 282 5.1. Point-to-point Ethernet VPN 284 In the seamless integration solution described in this document, PEs 285 participating in a VPN offer point-to-point Layer 2 connections 286 between different customer sites, and Ethernet is used as the Layer 2 287 hand-off between a PE and a CE. Under the seamless integration 288 solution, two different techniques can be used to establish P2P 289 Ethernet services under the same VPN: some P2P Ethernet services may 290 use the technique specified per [RFC6624], while others may use the 291 technique specified per [RFC8214]. [RFC6624] uses the terminology of 292 "Layer 2 VPN (L2VPN)". [RFC8214] uses the terminology of "Ethernet 293 VPN (EVPN)". In this document, we refer to a VPN that is capable of 294 offering Layer 2 Ethernet services by using both L2VPN and EVPN VPWS 295 technologies as a point-to-point Ethernet VPN. 297 5.2. Operation Model for Seamless Integration 299 A PE participating in a point-to-point Ethernet VPN offers P2P 300 Ethernet services with different remote PEs. By nature of point-to- 301 point service, there is no requirement for full mesh among all the 302 PEs participating in the same point-to-point Ethernet VPN instance. 304 The seamless integration solution allows the coexistence of composite 305 PE, L2VPN PE and EVPN PE under the same VPN instance. It allows the 306 establishment of P2P Ethernet services over the same MPLS/IP core: 307 (a) between two homogenous PEs, or (b) between a composite PE and a 308 L2VPN PE, or (c) between a composite PE and a EVPN PE. 310 A composite PE can establish a P2P Ethernet service with a L2VPN PE 311 and different a P2P service with an EVPN PE. It is the sole 312 responsibility of a composite PE to seamless integrate with L2VPN PEs 313 and EVPN PEs. 315 There will be no P2P service between an EVPN PE and a L2VPN PE in the 316 same L2 Ethernet VPN as an EVPN PE is provisioned only to provide the 317 procedure/function per EVPN VPWS. 319 5.3. Seamless Integration for Single Homing or Multihoming 321 L2VPN offers single home as well as active-standby multihoming 322 support, but not active-active multihoming support. Under the 323 seamless integration solution, a composite PE can integrate with 324 L2VPN PE(s) working in: 326 Case 1: single home 328 Case 2: active-standby multihoming with its peer L2VPN PE(s) 330 A composite PE supports seamless integration with EVPN PE(s) working 331 in: 333 Case 1: single home 335 Case 2: single-active multihoming with its peer EVPN PE(s) 336 Case 3: all-active multihoming with its peer EVPN PE(s) 338 While providing seamless integration solution, a composite PE may 339 provide single home support as well as single-active or all-active 340 multihoming support support to its locally attached CE. 342 For single-active multihoming, there are two options that a 343 multihomed CE may connect to a redundant set of composite PEs: 345 1. Through a LAG interface while the composite PEs working in a 346 port-active for single-active multihoming, and the DF or non-DF 347 role on the composite PE is elected on a per port basis. 349 2. Through a separate interface to each composite PE working in 350 single-active multihoming, and the DF or non-DF role on the 351 composite PE is elected on a per access interface basis. 353 5.4. Control Plane Overview 355 In the seamless integration solution, a L2VPN PE continues to use the 356 standard procedure per [RFC6624] without any change or additional new 357 procedure. An EVPN PE also continues to use procedure per [RFC8214] 358 without any change or additional new procedure. 360 A composite PE follows the seamless integration procedure defined in 361 this document. 363 A composite PE uses EVPN VPWS procedure per [RFC8214] to establish a 364 P2P Ethernet service with an EVPN PE. 366 5.5. Data Plane Overview 368 Regardless of the type of a PE, data traffic continues to be carried 369 over a MPLS/IP tunnel from an ingress PE to an egress PE. At the 370 egress PE, an MPLS label is used as the demultiplexer to identify the 371 attachment circuit for a P2P Ethernet service. 373 6. Seamless Integration Solution for Point-to-point Ethernet VPN 375 It is the sole responsibility of a composite PE to provide seamless 376 integration solution with a L2VPN PE. So the focus of the solution 377 is the composite PE. This section and its sub-sections follow 378 specify the solution and procedures a composite PE provides. 380 6.1. Local ID and Remote ID 382 Similar to other PEs, a composite PE is provisioned for the VPN it 383 participates through Route Target(s) and a Route Distinguisher (RD). 384 For each P2P Ethernet service, the PE involved is provisioned with a 385 pair of local and remote IDs. The local ID identifies an local 386 attachment circuit associated with a P2P service, while the remote ID 387 identifies an attachment circuit attached to a remote PE. 389 For a given P2P Ethernet service, a local ID for a PE is the remote 390 ID for its corresponding remote PE. It is required that that both 391 PEs involved in a P2P Ethernet service must have a matching pair of 392 local/remote IDs correspondingly. In the BGP signaling procedure for 393 auto-discovery, only local ID is signaled in the control plane, but 394 not remote ID. 396 In L2VPN, the ID used to identify an attachment circuit associated 397 with a P2P service is referred to as a VE ID or site ID which is a 398 16-bit integer. A valid VE-ID for L2VPN is in the range of 1 to 399 0xFFFE. 401 In EVPN VPWS, the ID used to identify an attachment associated with a 402 P2P service is referred as an EVPN VPWS service instance identifier 403 which is a 24-bit integer. A valid service instance identifier for 404 EVPN VPWS is in the range of 1 to 0xFFFFFF. 406 A p2p Ethernet service using L2VPN procedure MUST keep its local/ 407 remote ID within the range of 0x1 to 0xFFFE. 409 6.2. Composite PE Control Plane Procedure 411 This section and the sub-sections under it cover the control plane 412 procedure of a composite PE to interact with other types of PEs. 414 6.2.1. Auto-Discovery 416 All three types of PEs defined in this document continue to use MP- 417 BGP for auto-discovery. An auto-discovery procedure involves two 418 parts: A PE needs to identify itself for other PEs to discover it, 419 and a PE needs to auto discover other PEs. Auto-discovery is only 420 meaningful to PEs participating in the same VPN. 422 A composite PE needs to identify itself and discover other PE(s) 423 participating in the same point-to-point Ethernet VPN. If a 424 composite PE does not know a-priori the type of remote PE for a given 425 P2P Ethernet service it tries to establish, a composite PE MUST 426 participate in both L2VPN and EVPN auto-discovery procedures per 428 [RFC6624] and [RFC8214] except in the cases specified in section 429 6.2.5. 431 Similar to a L2VPN or EVPN PE, a composite PE uses Route Target 432 community to identify itself as a part of a point-to-point Ethernet 433 VPN instance. A composite PE announces itself through both BGP L2VPN 434 A-D route and EVPN E-AD per EVI route, and with the RT(s) belong to 435 the VPN it participates. A network operator may choose to use 436 different RT(s) to identify L2VPN PEs and EVPN PEs participating in 437 the same VPN. In this case, A composite PE needs to be provisioned 438 with RTs used by L2VPN PEs and EVPN PEs. 440 A composite PE discovers other L2VPN PEs by processing L2VPN A-D 441 routes that have route target(s) matching its import RT(s). At the 442 same time, a composite PE discovers other EVPN or composite PEs by 443 processing EVPN E-AD per EVI routes that have the RT(s) matching its 444 import RT(s). 446 At the end of discovery procedure, a L2VPN PE discovers all L2VPN PEs 447 and all composite PEs participating in the same VPN. However a L2VPN 448 cannot distinguish a L2VPN from a composite PE. From a point of 449 L2VPN PE, all composite PEs are L2VPN PEs. 451 Also at the end of discovery procedure, an EVPN PE discovers all EVPN 452 PEs and all composite PEs participating in the same VPN. Similarly, 453 an EVPN PE cannot distinguish an EVPN PE from a composite PE. From a 454 point of EVPN PE, all composite PEs are EVPN PEs. 456 6.2.2. Control Plane Signaling 458 In the seamless integration solution, a composite PE relies on MP-BGP 459 signaling to exchange information for each of its P2P Ethernet 460 service. A composite PE uses the procedures defined in [RFC6624] and 461 [RFC8214] for control plane signaling, and by default it originates 462 both a L2VPN route and an EVPN E-AD per EVI route for each of its P2P 463 Ethernet service. Note that these are the same routes used for auto- 464 discovery. 466 +-------------------------------+ 467 Composite PE1 L2VPN PE2 468 +--------+ +---> <---+ +--------+ 469 | +----+ | VE-ID=1 VE-ID=2 | +----+ | 470 CE1------+VPWS| | | |VPWS+-----CE2 471 | +----+ | +---> | +----+ | 472 +--------+ EthTag=1 +--------+ 473 | | 474 +-------------------------------+ 476 Figure 1: BGP-L2VPN and EVPN-VPWS integration 478 As it is shown in Figure 1 above, PE1 is provisioned to be a 479 composite PE. PE1 originates both L2VPN A-D route with local VE-ID 480 (1) as well as EVPN E-AD per EVI route with local Ethernet Tag ID (1) 481 in their corresponding NLRIs. PE2 is a L2VPN PE and it originates a 482 L2VPN A-D route with a local VE-ID (2) in its NLRI. A p2p Ethernet 483 service is established between PE1 and PE2 based the L2VPN procedure 484 per [RFC4761] when both PEs have the matching local/remote VE-IDs. 486 A composite PE may be optimized to originate either L2VPN route or 487 EVPN E-AD per EVI route, but not both based on its provisioning 488 model. Please see section 6.2.6 for detail. 490 If a CE is multihomed to composite PEs in multihoming mode, each 491 composite PE also originates an EVPN E-AD per ES route and EVPN 492 Ethernet segment per [RFC8214]. 494 6.2.3. Status of an Attachment Circuit 496 A composite PE uses status vector TLV to notify other L2VPN PEs 497 through its L2VPN route the status of its attachment circuit per . A 498 composite PE updates the corresponding L2VPN route with an updated 499 status vector when there is a status change in its attachment 500 circuit. 502 A composite PE withdraws its corresponding EVPN E-AD route per 503 procedure defined in [RFC8214] when its locally attached Ethernet 504 segment goes down. 506 6.2.4. Layer 2 Extended Community 508 A composite PE uses L2VPN info extended community for L2VPN per 509 [RFC6624]. It shall support L2 encapsulation of type 4 and type 5. 511 A composite PE uses EVPN Layer 2 attribute extended community 512 specified in [RFC8214] for EVPN, and it attaches the Layer 2 extended 513 community in the EVPN A-D route it originates. 515 6.2.5. Port-active Multihoming and DF election 517 For the seamless migration, it is desirable that a multihomed CE uses 518 a LAG interface to connect to a redundant set of composite PEs, such 519 that when L2VPN PE involved in a Layer 2 P2P Ethernet service is 520 migrated to support EVPN-VPWS, there is no need to touch the 521 multihomed CE device if at that stage the redundant set of composite 522 PEs are changed to provide all-active multihoming. 524 In addition, if the LACP protocol is running for the interface and 525 while in single-active scenario, it is recommended a non-DF composite 526 PE sends out-of-sync state for the interface instead of operational 527 down. To that end, each composite PE is required to play a DF or 528 non-DF role on a per port basis instead of per VLAN or per (ES, VLAN) 529 basis. 531 To support multihomed CE connecting to the composite PEs working in a 532 single-active multihoming scenario through a LAG interface, each 533 composite PE must support port-active load-balancing, similar as it 534 is specified in section 3 of [EVPN-MH-PA] except that a composite PE 535 must also provide L2VPN functionality per [RFC6624]. 537 Please note that per port DF/non-DF role can be achieved by using one 538 of the standard based DF election algorithms, as long as the 539 algorithm can be easily carried out on a per port basis, such as the 540 preference based DF election when both the ESI and preference are 541 configured on a per port basis. 543 Supporting port based single-active multihoming on the composite PEs 544 with its multihomed CE using LAG interface does not change the 545 control plane signaling, and it is oblivious to L2VPN PE. Since we 546 cannot change the behavior of a L2VPN PE, a composite PE will 547 continue to signal the preference for L2VPN on a per access interface 548 basis through the Layer 2 extended community alongside its 549 corresponding L2VPN A-D route. A L2VPN PE continues to carry the DF 550 election based on its normal L2VPN process. 552 6.2.6. Optimization 554 With the simplest provisioning model, if a composite PE does not know 555 a-priori whether the remote PE for a given P2P service is a L2VPN PE 556 or an EVPN PE, the composite needs to participate in the auto- 557 discovery and signaling procedures for both L2VPN and EVPN. This 558 works well as it allows a composite to establish a P2P service with 559 different types of PEs composite PE, and to switch from using a L2VPN 560 PW to EVPN VPWS dynamically during the migration process. 562 The simples provisioning model may not be optimal though, in that a 563 composite PE originates twice as many A-D routes as they are required 564 to establish the number of P2P services it is provisioned to. 565 Therefore in some scenario, it is desirable that a composite PE be 566 optimized to perform either L2VPN or EVPN VPWS procedure for a given 567 P2P service, but not both. 569 For a composite PE, if a Service Provider has the prior knowledge 570 about the types of remote PEs for some or all of its P2P Ethernet 571 services, reducing the number of routes a composite PE originates can 572 be achieved through the configuration. Based on the configuration, a 573 composite may advertise EVPN route but not L2VPN A-D route for a P2P 574 Ethernet service, or vice versa. It is up to the Service Provider to 575 decide based on the network requirement. 577 6.3. Composite PE Forwarding Procedure 579 A composite PE supports forwarding procedure defined in [RFC6624] and 580 [RFC8214]. 582 When a packet arrives at an ingress composite PE, the composite PE 583 adds a VPN service label based on the AC that packet arrives at, and 584 it encapsulates the packet and sends it through a tunnel to the 585 egress PE. 587 o A composite PE will not forward customer traffic to the L2VPN PE 588 playing a non-DF role 590 o If a composite PE detects that two or more EVPN PEs are attached 591 to the same ES and they are working in all-active mode, it will 592 load balance the traffic among the EVPN PEs. 594 o If a composite PE detects that two or more EVPN PEs are attached 595 to the same ES and they are working in single-active mode, it will 596 only forward the traffic to the EVPN PE playing a DF role. 598 o If a set of composites PEs work in all-active multihoming mode for 599 the same multihomed CE, then regardless of DF or Non-DF role each 600 composite PE plays, it must forward the packet received from its 601 multihomed CE to the remote L2VPN DF PE. 603 o If a composite PE receives both L2VPN and EVPN A-D routes from a 604 remote PE for the same p2p Ethernet service, the composite should 605 install forwarding routes in a make-before-break fashion: 607 a. For the traffic coming from the remote PE to its local access 608 interface direction, to achieve a fast failover, the composite 609 may install forwarding routes based on both L2VPN and EVPN A-D 610 routes. However, to save system resource in a scaled setup, 611 the composite may choose to install only the forwarding route 612 for the EVPN A-D route and it should do so before it deletes 613 the forwarding route for the L2VPN A-D route if it was 614 installed beforehand. 616 b. For traffic coming from its local access interface to the 617 remote PE direction, only one route can be installed for the 618 same local access interface. Forwarding should be based on 619 the EVPN A-D route. The composite PE should update the 620 forwarding route in a make-before-break fashion if the 621 forwarding route for L2VPN A-D route has already been 622 installed before the processing of the incoming EVPN A-D 623 route. 625 o If a composite PE receives both L2VPN and EVPN A-D routes from a 626 remote PE for the same p2p Ethernet service, and later on the 627 remote PE is reverted back to a L2VPN only PE and withdraws its 628 EVPN A-D route, the composite PE should also update the forwarding 629 route accordingly in a make-before-break fashion: 631 a. For the traffic coming from the remote PE to its local access 632 interface direction, if the forwarding route for the L2VPN A-D 633 route is not there, the composite PE should install the 634 forwarding route for the L2VPN A-D route before it tears down 635 the forwarding route for the EVPN A-D route. 637 b. For the traffic coming from its local access interface to the 638 remote PE direction, only one route can be installed for the 639 same local access interface. The composite PE should update 640 the forwarding route based on the L2VPN A-D route in a make- 641 before-break fashion. 643 o Upon reception of an A-D per EVI route and an L2VPN route for the 644 same P2P service, if both routes match the configured IDs, a 645 composite PE MUST select the EVPN route and forward the traffic 646 only to the EVPN PE, and not the L2VPN PE. 648 When a packet arrives at an egress PE, the VPN service label carried 649 in the packet is used as the demultiplexer to identify the AC 650 connecting to the destination CE. 652 6.4. Composite PE Procedures for All-Active Multi-Homing 654 Two or more Composite PEs MAY be attached to the same All-Active 655 multi-homed CE and still be seamlessly integrated in an L2VPN 656 network. This is illustrated in Figure 2. 658 +------------------------+ 659 + | 660 Composite PE11 | 661 +--------+ +---> | 662 | +----+ | VE-ID=1 | 663 +----------+VPWS| | | 664 | | +----+ | +---> L2VPN PE2 665 +---+ | +--------+ EthTag=1 +--------+ 666 |CE1+--+ LAG-1 | <---+ | +----+ | 667 | +--+ | VE-ID=2 | |VPWS+-----CE2 668 +---+ | Composite PE12 | +----+ | 669 | +--------+ +---> +--------+ 670 | | +----+ | VE-ID=1 | 671 +----------+VPWS| | | 672 | +----+ | +---> | 673 +--------+ EthTag=1 | 674 | | 675 +------------------------+ 677 Figure 2: L2VPN and EVPN-VPWS integration with all-active multi-homed 678 CEs 680 In the example of Figure 2, PE11 and PE12 are configured as composite 681 PEs with the same local CE identifiers. That is, both PEs are 682 configured with local VE-ID (1) and the same remote VE-ID (2). Also, 683 both will be configured with the same EVPN local Ethernet Tag (1) and 684 remote Ethernet Tag (2). As long as PE2 does not become a composite 685 PE or an EVPN PE, it will not import the A-D per-EVI routes and will 686 import the L2VPN routes only. PE2 will make a selection to use 687 either PE11 or PE12 to setup an L2VPN VPWS service. 689 For example, assuming PE11 is selected, PE2 forwards the traffic 690 coming from CE2 to PE11 (there is no per-flow load-balancing). In 691 case of failure, upon receiving the L2VPN rout withdraw from PE11, 692 PE2 will change its forwarding next-hop to PE12. 694 In the reverse direction, CE1 will perform per-flow load-balancing to 695 PE11 and PE12. Both PEs will program their forwarding paths to send 696 CE1 traffic to PE2. 698 The benefit of this solution is that when PE2 can be upgraded to an 699 EVPN or composite PE, the P2P service can be migrated to EVPN VPWS 700 with no changes on CE1 or PE11/PE12. 702 7. Extended Seamless Integration Solution for Multipoint Ethernet VPN 704 [RFC8560] specifies how EVPN and VPLS PEs can be seamlessly 705 integrated into the same network, assuming the VPLS PEs use [RFC4761] 706 or [RFC4762] procedures to setup the pseudowires to the remote VPLS 707 PEs or composite PEs. [RFC8560] procedures consider that CEs can be 708 multi-homed to two VPLS PEs, or to a group of composite PEs in a 709 single-active or port-active Ethernet Segment. All-active multi- 710 homing is out of scope. 712 This specification updates [RFC8560] in case All-Active multi-homing 713 is used on two or more composite PEs of the same multipoint VPN 714 service and the composite PEs and VPLS PEs use the BGP-VPLS [RFC4761] 715 control and data plane procedures. Seamless integration and All- 716 active multi-homing procedures for [RFC4762] VPLS is out of scope. 717 This document also updates [RFC8560] to clarify the required MAC 718 Flush procedures in case single-active/all-active/por-active multi- 719 homing is used on the composite PEs. 721 7.1. All-Active Multi-Homing and Seamless Integration for BGP-VPLS 722 services 724 All-active Ethernet Segments MAY be used in a VPLS service composed 725 of composite and BGP-VPLS PEs. Ethernet Segments are an EVPN 726 construct, hence only supported in composite PEs and not BGP-VPLS 727 PEs. Figure 3 illustrates an example of the use of All-active 728 Ethernet Segments and seamless integration between BGP-VPLS and EVPN. 730 +------------------------+ 731 + | 732 Composite PE11 BGP VPLS PE2 733 +--------+ +---> +--------+ 734 | +----+ | <---+ | +----+ | 735 +----------+EVI | | VE-ID=2 | |VPLS+-----CE2 736 | | +----+ | | +----+ | 737 +---+ | +--------+ +--------+ 738 |CE1+--+ LAG-1 | | 739 | +--+ + + 740 +---+ | Composite PE12 BGP VPLS PE3 741 | +--------+ +---> +--------+ 742 | | +----+ | <---+ | +----+ | 743 +----------+EVI | | VE-ID=3 | |VPLS+-----CE3 744 | +----+ | | +----+ | 745 +--------+ +--------+ 746 | | 747 +------------------------+ 749 Figure 3: BGP-VPLS and EVPN PEs with all-active multi-homing 751 In Figure 3, the composite PEs will be provisioned for EVPN and All- 752 active Multi-homing as specified in [RFC7432]. In addition, BGP-VPLS 753 is enabled on the same services. PE11 and PE12 will therefore 754 advertise the corresponding EVPN and BGP-VPLS routes. The EVPN 755 routes are only imported by PE11 and PE12, whereas the BGP-VPLS 756 routes are imported by all the PEs in the service. 758 In this case, the PEs MUST follow the procedures in [RFC8560] that 759 are repeated below for the reader's benefit: 761 o The composite PEs MUST place their EVPN MP2P service tunnels and 762 BGP-VPLS PWs in the same Split Horizon Group. I.e., traffic 763 coming from a BGP-VPLS PW MUST NOT be forwarded to an EVPN tunnel. 765 o If two composite PEs successfully attempt to setup a BGP-VPLS PW 766 and an EVPN tunnel, the BGP-VPLS pseudowire will be brought 767 operationally down. 769 o The composite PEs will not advertise any MAC/IP routes for MAC 770 address learned on a BGP-VPLS PW that is part of the Split Horizon 771 Group assigned to the EVPN tunnels. 773 In addition, this document updates [RFC8560] so that All-active 774 multi-homing Ethernet Segments MAY exist in the composite PEs. If an 775 all-active multi-homing ES is defined in a group of composite PEs, 776 all the BDs associated to the LAG MUST support and follow the EVPN 777 multi-homing procedures. 779 If a group of composite PEs work in all-active multihoming and 780 another group of composite PEs work in single-active, normal EVPN 781 procedure will be used between these two group of composite PEs. 783 If a group of composite PEs work in all-active multihoming and remote 784 BGP-VPLS PEs work in single-active, BGP-VPLS procedure will be used 785 between composite PEs and BGP-VPLS PEs. 787 When all-active multi-homing is used, a MAC flip-flopping effect will 788 exist on the BGP-VPLS PEs. In Figure 3, this effect results in CE1's 789 MAC moving between two different PWs in PE2 and PE3. E.g., at first 790 CE1 may hash the traffic to PE11, and PE2 may learn CE1's MAC on its 791 pseudowire PE2-PE11. Later, if CE1 hashes the traffic (for a 792 different flow) to PE12, PE2 will move CE1's MAC to its PW PE2-PE12. 793 This MAC move or "flip-flopping" can happen continuously and may have 794 harmful consequences for the BGP-VPLS PEs. In some cases, the BGP- 795 VPLS PEs will consider this to be a loop. 797 The solution to avoid the MAC "flip-flopping" is based on the support 798 of "MAC Pinning" on the BGP-VPLS PEs, as follows: 800 o In Figure 3, the composite PEs and BGP-VPLS PEs will setup their 801 PWs normally. 803 o The MAC flip-flopping effect would be avoided by enabling MAC 804 Pinning on the PE2 and PE3 pseudowires. 806 o With MAC Pinning enabled, PE2 and PE3 will learn CE1's MAC on only 807 one PW and will not be relearned in the same or different PW until 808 the MAC ages out. E.g., consider CE1 hashes the first flow to 809 PE11 and PE11 forwards to PE2. PE2 learns CE1's MAC on PW 810 PE2-PE11. Since MAC Pinning is applied on that PW, subsequent 811 frames arriving at PW PE2-PE12 with CE1's MAC will not trigger a 812 relearn process on PE2. 814 MAC Pinning is assumed to be supported by all the BGP-VPLS PEs in the 815 network, therefore no upgrade is required on the BGP-VPLS PEs to 816 support this specification. 818 7.2. Extensions for MAC Flush 820 Irrespective of the type of multi-homing used on the composite PEs, 821 in case of a failure on the Ethernet Segment (node or link failure) 822 the composite PEs MUST indicate the need to flush MAC addresses to 823 the remote BGP-VPLS PEs. 825 E.g., in Figure 3, consider CE1's MAC is learned on PW PE2-PE11 (on 826 PE2). If the link CE1-PE11 fails, PE2 will continue sending the 827 unicast traffic to CE1 using the PW to PE11, and therefore causing a 828 blackhole until CE1's MAC ages out. 830 A MAC flush mechanism is required in order to speed up the 831 convergence in case of ES failures. This requires some extensions to 832 [RFC8560] and it will be added in future versions. 834 8. IANA Considerations 836 This document raises no new IANA request. There is no IANA actions. 838 9. Security Considerations 840 This document does not introduce any new security concern. This 841 document inherits the same security as they are specified in 842 [RFC6624] and [RFC8214]. 844 10. Acknowledgements 846 The authors would like to thank Hitesh Mali and Vasu Venkatraman for 847 their valuable comments and feedbacks. They would also like to thank 848 John Drake for his review and support. 850 11. Contributors 852 In addition to the authors listed, the following individuals also 853 contributed to this document: 855 Vinod Prabhu, Nokia 857 12. References 859 12.1. Normative References 861 [EVPN-MH-PA] 862 Brissette, P., Thoria, S., and A. Sajassi, "EVPN multi- 863 homing port-active load-balancing", internet-draft draft- 864 brissette-bess-evpn-mh-pa-04, March 2019. 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, 868 DOI 10.17487/RFC2119, March 1997, 869 . 871 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 872 LAN Service (VPLS) Using BGP for Auto-Discovery and 873 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 874 . 876 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 877 Virtual Private Networks Using BGP for Auto-Discovery and 878 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 879 . 881 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 882 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 883 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 884 2015, . 886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 888 May 2017, . 890 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 891 Rabadan, "Virtual Private Wire Service Support in Ethernet 892 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 893 . 895 [RFC8560] Sajassi, A., Ed., Salam, S., Del Regno, N., and J. 896 Rabadan, "Seamless Integration of Ethernet VPN (EVPN) with 897 Virtual Private LAN Service (VPLS) and Their Provider 898 Backbone Bridge (PBB) Equivalents", RFC 8560, 899 DOI 10.17487/RFC8560, May 2019, 900 . 902 12.2. Informative References 904 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 905 "Encapsulation Methods for Transport of Ethernet over MPLS 906 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 907 . 909 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 910 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 911 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 912 . 914 Authors' Addresses 916 Wen Lin 917 Juniper Networks, Inc. 919 EMail: wlin@juniper.net 920 Bin Wen 921 Comcast 923 EMail: bin_wen@comcast.com 925 Voiteck Kozak 926 Comcast 928 EMail: voitek_kozak@comcast.com 930 Jorge Rabadan 931 Nokia 933 EMail: jorge.rabadan@nokia.com