idnits 2.17.1 draft-brissette-bess-evpn-vpws-seamless-04.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 (July 12, 2021) is 1019 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 == Outdated reference: A later version (-10) exists of draft-ietf-bess-evpn-mh-pa-03 == Outdated reference: A later version (-08) exists of draft-ietf-bess-evpn-vpws-fxc-03 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Working Group P. Brissette 3 Internet-Draft A. Sajassi 4 Intended status: Standards Track LA. Burdet 5 Expires: January 13, 2022 Cisco Systems 6 W. Lin 7 Juniper 8 J. Rabadan 9 Nokia 10 J. Uttaro 11 ATT 12 D. Voyer 13 Bell Canada 14 I. Ghamari 15 Linkedin 16 E. Leyton 17 Verizon Wireless 18 B. Wen 19 V. Kozak 20 Comcast 21 July 12, 2021 23 EVPN-VPWS Seamless Integration with L2VPN VPWS 24 draft-brissette-bess-evpn-vpws-seamless-04 26 Abstract 28 This document presents a solution for migrating L2VPN Virtual Private 29 Wire Service (VPWS) to Ethernet VPN Virtual Private Wire Service 30 (EVPN-VPWS) services. The solution allows the coexistence of EVPN 31 and L2VPN services under the same point-to-point VPN instance. By 32 using this seamless integration solution, a service provider can 33 introduce EVPN into their existing L2VPN network or migrate from an 34 existing L2VPN based network to EVPN. The migration may be done per 35 pseudowire or flexible-crossconnext (FXC) service basis. This 36 document specifies control-plane and forwarding behaviors. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119] and 43 RFC 8174 [RFC8174]. 45 Status of This Memo 47 This Internet-Draft is submitted in full conformance with the 48 provisions of BCP 78 and BCP 79. 50 Internet-Drafts are working documents of the Internet Engineering 51 Task Force (IETF). Note that other groups may also distribute 52 working documents as Internet-Drafts. The list of current Internet- 53 Drafts is at https://datatracker.ietf.org/drafts/current/. 55 Internet-Drafts are draft documents valid for a maximum of six months 56 and may be updated, replaced, or obsoleted by other documents at any 57 time. It is inappropriate to use Internet-Drafts as reference 58 material or to cite them other than as "work in progress." 60 This Internet-Draft will expire on January 13, 2022. 62 Copyright Notice 64 Copyright (c) 2021 IETF Trust and the persons identified as the 65 document authors. All rights reserved. 67 This document is subject to BCP 78 and the IETF Trust's Legal 68 Provisions Relating to IETF Documents 69 (https://trustee.ietf.org/license-info) in effect on the date of 70 publication of this document. Please review these documents 71 carefully, as they describe your rights and restrictions with respect 72 to this document. Code Components extracted from this document must 73 include Simplified BSD License text as described in Section 4.e of 74 the Trust Legal Provisions and are provided without warranty as 75 described in the Simplified BSD License. 77 Table of Contents 79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 80 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 6 81 3. L2VPN PE, EVPN-VPWS PE and Composite PE . . . . . . . . . . . 7 82 4. Solution Requirements . . . . . . . . . . . . . . . . . . . . 8 83 5. Seamless Integration Solution . . . . . . . . . . . . . . . . 8 84 6. Capability Discovery . . . . . . . . . . . . . . . . . . . . 9 85 7. Data Plane Operations . . . . . . . . . . . . . . . . . . . . 10 86 8. Control Plane Operations . . . . . . . . . . . . . . . . . . 11 87 9. Multi-homed Operations . . . . . . . . . . . . . . . . . . . 13 88 9.1. Operations with Port-Active MH PEs . . . . . . . . . . . 13 89 9.2. Operation with Single-Active MH PEs . . . . . . . . . . . 14 90 9.3. Operation with All-Active MH PEs . . . . . . . . . . . . 14 91 9.3.1. Falling back to port-active . . . . . . . . . . . . . 14 92 9.3.2. Asymmetric forwarding . . . . . . . . . . . . . . . . 15 94 10. Route Optimization . . . . . . . . . . . . . . . . . . . . . 16 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 96 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 98 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 100 14.2. Informative References . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 103 1. Introduction 105 Point-to-point L2VPN solutions are specified in [RFC8077] when LDP- 106 based pseudowire are offered. BGP-based L2VPN service may also offer 107 point-to-point service using [RFC6624] or by setting up auto- 108 discovered VPN members using [RFC6074] and then the pseudowires using 109 [RFC8077]. 111 EVPN-VPWS leverages the latest EVPN technology and brings extra 112 functions to Layer 2 point-to-point Ethernet service, such as all- 113 active redundancy, load balancing and mass withdrawal. All-active 114 redundancy also makes it easier to achieve fast convergence on an 115 access link or node failure. 117 When expanding an existing L2VPN network with Ethernet encapsulation, 118 a service provider may want to deploy EVPN-VPWS to provide additional 119 Layer 2 point-to-point Ethernet services, and at the same time some 120 of the customer traffic may still need to be terminated on the 121 existing L2VPN PEs within the service provider network. 123 This document describes a seamless-integration solution that allows 124 the co-existence of L2VPN point-to-point Ethernet services and EVPN- 125 VPWS procedure per [RFC8214] under the same VPN network and over the 126 same MPLS/IP network. Service providers may also use the seamless 127 integration solution to migrate traditional L2VPN network to EVPN- 128 VPWS based network. 130 MPLS/IP Core 131 +---------------+ 132 +---+ | | +---+ 133 |PE1|----|----- PW1 -----|---|PE2| L2VPN VPWS 134 | |----|---+ | +---+ 135 +---+ | | | 136 EVPN-VPWS & | +--PW2---+ | +---+ 137 L2VPN VPWS | +--|---|PE3| EVPN-VPWS 138 (Composite) | | +---+ 139 +---------------+ 141 Seamless Integration of EVPN-VPWS. 143 Figure 1 145 Figure 1 shows a network where PE1 runs in hybrid mode (EVPN-VPWS and 146 legacy L2VPN VPWS). PE1 has established a pseudowire (PW1) with PE2 147 running L2VPN VPWS. Also, it has initiated another pseudowire (PW2) 148 with PE3 running EVPN-VPWS. In the future, PE2 may be upgraded to 149 EVPN-VPWS seamlessly. The seamless integration solution described in 150 this document has the following attributes: 152 - It is backward compatible with [RFC8214] and EVPN Flexible 153 crossconnect service [I-D.ietf-bess-evpn-vpws-fxc] documents. 155 - New PEs can leverage the multi-homing mechanisms and provisioning 156 simplifications of EVPN Ethernet-Segment framework: 158 a. Auto-sensing of MHN / MHD 160 b. Auto-discovery of redundancy groups 162 c. Auto-election of Designated Forwarder and VLAN carving 164 d. Support of various load-balancing modes such as port-active, 165 single-active and all-active 166 MPLS/IP Core 167 +---------------+ 168 +---+ | | +---+ 169 |PE1|----|----- PW1 -----|---|PE2| 170 +---+ | L2VPN | +---+ 171 L2VPN | | L2VPN 172 VPWS +---------------+ VPWS 173 ... 174 +---------------+ 175 +---+ | | +---+ 176 |PE1|----|----- PW1 -----|---|PE2| 177 +---+ | L2VPN | +---+ 178 L2VPN | | L2VPN VPWS 179 VPWS +---------------+ + EVPN-VPWS 180 .... 181 +---------------+ 182 +---+ | | +---+ 183 |PE1|----|----- PW1 -----|---|PE2| 184 +---+ | EVPN-VPWS | +---+ 185 L2VPN VPWS | | L2VPN VPWS 186 + EVPN-VPWS +---------------+ + EVPN-VPWS 187 .... 188 +---------------+ 189 +---+ | | +---+ 190 |PE1|----|----- PW1 -----|---|PE2| 191 +---+ | EVPN-VPWS | +---+ 192 EVPN-VPWS | | EVPN-VPWS 193 +---------------+ 195 Migration from L2VPN to EVPN-VPWS. 197 Figure 2 199 Figure 2 illustrates the migration of a L2VPN VPWS brownfield network 200 to EVPN-VPWS. For example, let say initially PE1 and PE2 have a 201 L2VPN PW established between them. First, a network operator may 202 upgrade PE2 to enable EVPN-VPWS. Once upgraded, PE2 which now has 203 the EVPN-VPWS capability still runs L2VPN PW with PE1. Later on, a 204 network operator may decide to upgrade PE1 to support EVPN-VPWS. As 205 soon as the upgrade is completed, PE1 and PE2 auto-discover their 206 respective EVPN routes and the corresponding point-to-point service. 207 That EVPN-VPWS service taked higher precedence over existing legacy 208 L2VPN pseudowire. Finally, the network operator may safely remove 209 any legacy configurations from PE1 and PE2 nodes while PW remains 210 established using EVPN-VPWS. 212 2. Terms and Abbreviations 214 o CE: A Customer Edge device, e.g., a host, router, or switch. 216 o DF: EVPN Ethernet Segment Designated Forwarder. 218 o NDF: EVPN Ethernet Segment Non-Designated Forwarder. 220 o Ethernet Segment (ES): Refers to the set of Ethernet links that 221 connects a customer site (device or network) to one or more PEs. 223 o Ethernet Tag: An Ethernet Tag identifies a particular pseudowire, 224 e.g. a PW-ID as per [RFC8214]. 226 o FEC: Forwarding Equivalence Class. 228 o homogeneous PEs: Refers to PEs that are of the same types. 230 o LDP-LM: LDP Label Mapping Message. 232 o LDP-LW: LDP Label Withdraw Message. 234 o LSP: Label Switched Path. 236 o MHD: Multi-Homed Device. 238 o MHN: Multi-Homed Network. 240 o P2P: Point to Point - a P2P LSP typically refers to a LSP for 241 Layer2 pseudowire. 243 o PE: Provider Edge device. 245 o VPWS: Virtual Private Wire Service. It refers to L2VPN VPWS 246 circuit where pseudowires are signaled using LDP or BGP-AD 247 protocol. The latter is referred as VPWS A-D. 249 o EVPN-VPWS: Ethernet-VPN Virtual Private Wire Service. It refers 250 to EVPN-VPWS circuit where pseudowires are signaled via BGP-EVPN. 251 It can also refer to [I-D.ietf-bess-evpn-vpws-fxc]. 253 o EVPN-FXC: Ethernet-VPN Flexible Cross-connect Service 254 [I-D.ietf-bess-evpn-vpws-fxc]. 256 o Port-Active Redundancy Mode: When only a single PE, among all the 257 PEs attached to an Ethernet segment, is allowed to forward traffic 258 to/from that Ethernet segment for a given interface, then the 259 Ethernet Segment is defined to be operating in Port-Active 260 redundancy mode. 262 o Single-Active Redundancy Mode: When only a single PE, among all 263 the PEs attached to an Ethernet segment, is allowed to forward 264 traffic to/from that Ethernet segment for a given VLAN, then the 265 Ethernet Segment is defined to be operating in Single-Active 266 redundancy mode. 268 o All-Active Redundancy Mode: When all PEs attached to an Ethernet 269 Segment are allowed to forward traffic to/from that Ethernet 270 segment for a given VLAN, then the Ethernet segment is defined to 271 be operating in All-Active redundancy mode. 273 o VPWS A-D: Refers to Virtual Private Wire Services with BGP-based 274 Auto Discovery as in [RFC6074]. 276 o PW: Pseudowire 278 3. L2VPN PE, EVPN-VPWS PE and Composite PE 280 There are three types of PEs defined in the seamless integration 281 solution: L2VPN PE, EVPN-VPWS PE and composite PE. Under a given 282 Layer 2 Ethernet VPN, the type of PE is categorized by the technology 283 it is provisioned for. For instance, a PE that is provisioned to use 284 L2VPN and EVPN-VPWS on the same VPN service is considered a composite 285 PE. 287 Also in this document, in the context of a given Layer 2 Ethernet 288 VPN, an EVPN-VPWS PE is a PE that is provisioned to provide only the 289 EVPN solution per [RFC8214] or [I-D.ietf-bess-evpn-vpws-fxc] but not 290 a seamless integration solution. It is irrelevant whether an EVPN- 291 VPWS PE is capable to support a seamless integration solution. 293 For example, for a non-L2VPN PE, a network administrator may know a 294 priori that the PE does not need to establish any P2P Ethernet 295 service that involves L2VPN PE under a given Layer 2 Ethernet VPN 296 instance. In this case, the PE can be provisioned to act only as an 297 EVPN-VPWS PE for that VPN even though it is capable of providing 298 seamless integration procedure. If such prior knowledge is 299 unavailable, then a PE SHALL be provisioned to act as a composite PE 300 if it is capable of. Otherwise, it is unable to establish a P2P 301 Ethernet service with a L2VPN PE. 303 Unless explicitly specified in this specification, a PE's type 304 applies to a given Layer 2 Ethernet VPN instance. A PE may act as an 305 EVPN-VPWS PE for one VPN, but as a composite PE for another VPN. 307 4. Solution Requirements 309 The seamless integration solution for point-to-point Ethernet VPN 310 meets the following requirements: 312 o It must allow L2VPN, EVPN-VPWS and composite PEs to participate in 313 the same Layer 2 Ethernet VPN instance. 315 o The solution MUST allow for staged migration towards EVPN-VPWS on 316 a site-by-site basis - e.g., new EVPN-VPWS sites to be provisioned 317 on EVPN-VPWS Provider Edge devices (PEs). Migration SHOULD be 318 possible on a per-pseudowire basis. 320 o The solution MUST NOT require any changes to existing L2VPN PEs 321 running Legacy VPWS, unless it is to upgrade them to EVPN-VPWS and 322 make them composite PE. 324 o The solution MUST allow for the co-existence of composite PE 325 devices running EVPN-VPWS and L2VPN VPWS for the same single-homed 326 and/or multi-homed segments. 328 o The solution MUST support port-active redundancy of multi-homed 329 networks and multi-homed devices for L2VPN, EVPN-VPWS and 330 composite PEs. 332 o The solution MUST support single-active redundancy of multi-homed 333 networks and multi-homed devices for L2VPN, EVPN-VPWS and 334 composite PEs. 336 o The solution SHOULD support all-active redundancy of multi-homed 337 Ethernet Segments for L2VPN, EVPN-VPWS and composite PEs. 339 o Composite PEs provisioned for all-active multihoming for their 340 multihomed CE(s) MAY work with L2VPN PE(s) working in single home 341 or active-standby multihoming. 343 These requirements collectively allow for the seamless insertion of 344 the EVPN-VPWS technology into brownfield L2VPN VPWS deployments. 346 5. Seamless Integration Solution 348 To support seamless integration, the solution may require L2VPN PEs 349 to setup PWs per [RFC8077] or [RFC6624] or may require L2VPN PEs to 350 setup VPWS service by auto-discovering VPN members using [RFC6074] 351 and then setting up the PWs using [RFC8077]. Furthermore, composite 352 PEs must support BGP EVPN routes per [RFC8214] and as per 353 [I-D.ietf-bess-evpn-vpws-fxc] and one of a method of legacy VPWS 354 technologies. All the logic for seamless integration SHALL reside on 355 the composite PEs. 357 A PE participating in a point-to-point Ethernet VPN offers P2P 358 Ethernet services with different remote PEs. By nature of point-to- 359 point service, there is no requirement for full-mesh among all the 360 PEs participating in the same point-to-point Ethernet VPN instance. 362 The seamless integration solution allows the coexistence of composite 363 PE, L2VPN PE and EVPN-VPWS PE under the same VPN instance. It allows 364 the establishment of P2P Ethernet services over the same MPLS/IP 365 core: (a) between two homogenous PEs, or (b) between a composite PE 366 and a L2VPN PE, or (c) between a composite PE and a EVPN-VPWS PE. 368 A composite PE can establish a P2P Ethernet service with a L2VPN PE 369 and different a P2P service with the same or a different EVPN-VPWS 370 PE. It is the sole responsibility of a composite PE to seamless 371 integrate with L2VPN PEs and EVPN-VPWS PEs. 373 There will be no P2P service between an EVPN-VPWS PE and a L2VPN PE 374 in the same L2 Ethernet VPN as an EVPN-VPWS PE is provisioned only to 375 provide the procedure/function per EVPN-VPWS. 377 6. Capability Discovery 379 The EVPN-VPWS PEs MUST advertise both BGP VPWS Auto-Discovery (VPWS 380 A-D) route or LDP-LM message as well as the BGP EVPN Ethernet-AD per 381 EVI route for a given pseudowire. Auto-discovery is only meaningful 382 to PEs participating in the same VPN. 384 In the case of L2VPN PEs running VPWS A-D, they may advertise the BGP 385 VPWS A-D route, per the procedures specified in [RFC4664] and 386 [RFC6074] or [RFC6624]. The operator may decide to use the same BGP 387 Route Target (RT) to identify a pseudowire on both EVPN-VPWS and 388 L2VPN networks. In this case, when a L2VPN PE receives the EVPN 389 Ethernet-AD per EVI route, it MUST ignore it on the basis that it 390 belongs to an unknown SAFI. However, the operator may choose to use 391 two RTs - one to identify the pseudowire on L2VPN network and another 392 for EVPN-VPWS network and employ RT-constrained [RFC4684] in order to 393 prevent BGP EVPN routes from reaching the L2VPN PEs. 395 When an EVPN-VPWS PE receives both a VPWS A-D route or a LDP-LM 396 message as well as an EVPN-VPWS Ethernet-AD per EVI route from a 397 given remote PE for the same pseudowire, it MUST give preference to 398 the EVPN-VPWS route for discovery. This ensures that, at the end of 399 the route exchange, all EVPN-VPWS capable PEs discover other EVPN- 400 VPWS capable PEs. 402 When the discovery phase is completed, the composite PEs have 403 discovered the remote PE per pseudowire along with their associated 404 capability (EVPN-VPWS or L2VPN), whereas the L2VPN PE have discovered 405 the remote PE per pseudowire as if they are L2VPN-only PEs. 406 Basically, a L2VPN PE discovers all L2VPN PEs and all composite PEs 407 participating in the same VPN. However, a L2VPN cannot distinguish a 408 L2VPN from a composite PE. From a point of L2VPN PE, all composite 409 PEs are L2VPN PEs. 411 Also, an EVPN-VPWS PE discovers all EVPN PEs and all composite PEs 412 participating in the same VPN. Similarly, an EVPN-VPWS PE cannot 413 distinguish an EVPN-VPWS PE from a composite PE. From a point of 414 EVPN-VPWS PE, all composite PEs are EVPN-VPWS PEs. 416 7. Data Plane Operations 418 When a packet arrives at an ingress composite PE, the composite PE 419 adds a VPN service label based on the AC that packet arrives at, and 420 it encapsulates the packet and sends it through a pseudowire to the 421 egress PE. 423 o A composite PE will not forward customer traffic to the L2VPN PE 424 playing a non-DF role 426 o If a composite PE detects that two or more EVPN-VPWS PEs are 427 attached to the same ES and they are working in all-active mode, 428 it will load balance the traffic among the EVPN-VPWS PEs. 430 o If a composite PE detects that two or more EVPN-VPWS PEs are 431 attached to the same ES and they are working in single-active 432 mode, it will only forward the traffic to the EVPN-VPWS PE playing 433 a DF role. Similar logic is followed with port-active mode. 435 o If a set of composites PEs work in all-active multihoming mode for 436 the same multihomed CE, then regardless of DF or Non-DF role each 437 composite PE plays, it may forward the packet received from its 438 multihomed CE to the remote L2VPN DF PE. Detailed description is 439 done in Section 9.3. 441 o If a composite PE receives both L2VPN and EVPN A-D routes from a 442 remote PE for the same p2p Ethernet service, the composite should 443 install forwarding routes in a make-before-break fashion: 445 A. For the traffic coming from the remote PE to its local access 446 interface direction, to achieve a fast failover, the composite 447 may install forwarding routes based on both L2VPN and EVPN A-D 448 routes. However, to save system resources in a scaled setup, 449 the composite may choose to install only the forwarding route 450 for the EVPN A-D route and it should do so before it deletes 451 the forwarding route for the L2VPN A-D route if it was 452 installed beforehand. 454 B. For traffic coming from its local access interface to the 455 remote PE direction, only one route can be installed for the 456 same local access interface. Forwarding should be based on 457 the EVPN A-D route. The composite PE should update the 458 forwarding route in a make-before-break fashion if the 459 forwarding route for L2VPN A-D route has already been 460 installed before the processing of the incoming EVPN A-D 461 route. 463 o If a composite PE receives both L2VPN and EVPN A-D routes from a 464 remote PE for the same p2p Ethernet service, and later on the 465 remote PE has reverted back to a L2VPN only PE and withdraws its 466 EVPN A-D route, the composite PE should also update the forwarding 467 route accordingly in a make-before-break fashion: 469 A. For the traffic coming from the remote PE to its local access 470 interface direction, if the forwarding route for the L2VPN A-D 471 route is not there, the composite PE should install the 472 forwarding route for the L2VPN A-D route before it tears down 473 the forwarding route for the EVPN A-D route. 475 B. For the traffic coming from its local access interface to the 476 remote PE direction, only one route can be installed for the 477 same local access interface. The composite PE should update 478 the forwarding route based on the L2VPN A-D route in a make- 479 before-break fashion. 481 8. Control Plane Operations 483 Figure 3 demonstrates a typical brown-field deployment where PE1 is a 484 composite PE and PE2 is a L2VPN PE. 486 MPLS/IP 487 Composite PE Core L2VPN PE 488 +---------------+ 489 +---+ | | +---+ 490 |PE1|----|----- PW1 -----|---|PE2| 491 +---+ | | +---+ 492 +---------------+ 494 VPWS A-D route ] TX TX [ VPWS A-D route 495 or ] ---> <--- [ or 496 LDP Label Mapping ] [ LDP Label Mapping 498 AND 499 TX 500 EVPN per EVI/EAD ] ---> 502 EVPN-VPWS Single-Homed 504 Figure 3 506 The control plane procedures of L2VPN PEs are per [RFC8077], 507 [RFC4761] and [RFC4762]. 509 The EVPN-VPWS PE procedures are as follow: 511 o The composite PE MUST establish a PW to each remote PE from which 512 it has received only a VPWS A-D route or a LDP-LM message for the 513 corresponding pseudowire, and MUST set up the label stack 514 corresponding to the PW FEC. 516 o If an composite PE receives a VPWS A-D route or a LDP-LM message 517 from a given PE, it sets up a L2VPN VPWS PW to that PE. If it 518 then receives an EVPN Ethernet-AD per EVI route for that PW from 519 the same PE, then the composite PE may bring the L2VPN PW 520 operationally down and MUST forward traffic using the label 521 information from the EVPN Ethernet-AD per EVI route. 523 o If an composite PE receives an EVPN Ethernet-AD per EVI route 524 followed by a VPWS A-D route or a LDP-LM message from the same PE, 525 then the composite PE will setup the EVPN-VPWS PW. It may keep 526 the L2VPN VPWS PW operationally down and MUST forward traffic 527 using the reachability information from that EVPN Ethernet-AD per 528 EVI route. 530 o For L2VPN PEs not using VPWS A-D or LDP signaling, the composite 531 PEs need to be provisioned manually with PWs to those remote L2VPN 532 PEs for each pseudowire. In that case, if an composite PE 533 receives an EVPN Ethernet-AD per EVI route from a PE to which a PW 534 exists, it may keep VPWS PW operationally down and MUST forward 535 traffic using the reachability information from that EVPN 536 Ethernet-AD per EVI route. 538 In the case where a composite PE receives an EVPN Ethernet-AD per EVI 539 route for an established L2VPN PW from a different PE, the result 540 should be directed by a local configuration. This is to avoid any 541 security breach where a malicious user may want to steer an existing 542 connection to a different PE. 544 9. Multi-homed Operations 546 Figure 4 demonstrates a multi-homing scenario. CE1 is connected to 547 PE1 and PE2 where PE1 is the designated forwarder while PE2 is the 548 non-designated forwarder. 550 MPLS/IP 551 Composite PE Core L2VPN PE 552 +---------+ 553 DF +---+ | | +---+ +---+ 554 +--|PE1|----|---------|---|PE3|---|CE2| 555 +---+/ +---+ | PW1 /| +---+ +---+ 556 |CE1| | / | 557 +---+\ +---+ | / | 558 +--|PE2|----|-----+ | 559 NDF +---+ | | 560 +---------+ 562 EVPN-VPWS Multi-homing Redundancy 564 Figure 4 566 9.1. Operations with Port-Active MH PEs 568 In Figure 4, PE1 and PE2 are configured in port-active load-balancing 569 mode. Both PEs are advertising EVPN Ethernet-AD per ES route with 570 the single-active bit set as described in [I-D.ietf-bess-evpn-mh-pa]. 571 In this example, PE1 is DF elected for the shared Ethernet-Segment 572 identifier. 574 o Only PE1, as DF, advertises the VPWS A-D route or LDP-LM message 575 towards remote PE3. 577 o PE1 advertises the EVPN Ethernet-AD per EVI route for PW1 towards 578 remote PE3. The P-bit in L2 Attributes Extended Community is set 579 for PE1 as per [RFC8214]. The purpose is to have all required 580 EVPN-VPWS routes on remote PE. During an upgrade from L2VPN to 581 EVPN-VPWS, those remote nodes are immediately upgraded. 583 o PE2, as NDF, only advertises its EVPN Ethernet AD per EVI route 584 corresponding to that same PW1. The B-bit in L2 Attributes 585 Extended Community is set for PE2 as per [RFC8214] 587 Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN 588 Ethernet Segment DF Election procedures described in [RFC8214] for 589 EVPN-VPWS. Furthermore, PE1 withdraws its VPWS A-D route or sends 590 LDP-LW message to remote PE3 to teardown the L2VPN PW. Finally, PE2 591 advertises corresponding VPWS A-D route or LDP-LM message for that 592 PW1 and re-establish L2VPN PW with new PE2 destination. 594 If PE3 is running 2-way pseudowire redundancy and PW-status is 595 enabled, PE2 may leverage the existence of standby/backup PW with 596 PE3. In this particular scenario, PE2 may advertise VPWS A-D route 597 or LDP-LM message along with PW-status message. 599 Once PE3 is upgraded and support EVPN-VPWS, seamless integration 600 procedures are applied. Higher precedence of EVPN-VPWS over L2VPN 601 VPWS allow all PEs to avoid the usage of legacy circuit. Then, non- 602 preferred L2VPN VPWS protocols and configuration may be removed from 603 all PEs. 605 9.2. Operation with Single-Active MH PEs 607 Single-active operation is similar to Port-active load-balancing mode 608 described above. The main difference resides in the Designated 609 Forwarder election where the carving is performed at the circuit 610 level instead being of at the port/interface level. 612 9.3. Operation with All-Active MH PEs 614 In EVPN-VPWS all-active load-balancing mode, all PEs participating in 615 a redundancy group forward traffic bidirectionally, reducing the 616 importance of DF and NDF PE. However, L2VPN PEs do NOT support all- 617 active peering PEs as remote endpoints. 619 9.3.1. Falling back to port-active 621 Composite PE discovering remote L2VPN PE MAY fallback into port- 622 active load-balancing mode. That can be achieved dynamically or by 623 enforcing network operators to configure port-active instead of all- 624 active load-balacing mode. In both cases, port-active multi-homing 625 operations, as described before, apply here 627 9.3.2. Asymmetric forwarding 629 As per figure Figure 4, peering PEs run in all-active load-balancing 630 mode while PE3 behaves as single-homed PE. Asymmetric forwarding 631 consists of transmitting traffic in an all-active manner from peering 632 PEs to PE3 while the reverse direction is done in port-active or 633 single-active manner. 635 Traffic from CE1 going to PE1 is forwarded to PE3 using the VPN label 636 learned from VPWS AD route or LDP-LM message received from PE3. 637 Traffic from CE1 going to PE2 is forwarded to PE3 using that same VPN 638 label. Traffic coming from CE2 to PE3 gets forwarded only over the 639 primary PW towards PE1; the DF PE. Supporting asymmetric forwarding 640 with L2VPN PE requires extensions to EVPN-VPWS MH procedures. 642 For BGP VPWS, PE1 and PE2 naturally receive the same label from PE3 643 via BGP. They can use the same label when sending to PE3. There is 644 no direct need for alias label signaling. For LDP VPWS, since the 645 LDP sessions are targeted, PE1 and PE2 always receive different 646 labels, hence the alias label procedure is needed. 648 Following rules are applied to achieve expected behavior: 650 o Peering PEs advertise EVPN Ethernet-AD per ES route with the 651 single-active bit unset. That is to get the network ready when 652 remote L2VPN PE are upgraded to composite PE. 654 o DF PE advertises VPWS AD routes or LDP-LM message and EVPN 655 Ethernet AD per EVI route per PW. 657 o NDF PE advertises only EVPN Ethernet AD per EVI route per PW. 659 o If PE3 is running 2-ways pseudowire redundancy, PE2 may leverage 660 the existence of standby/backup PW with PE3. PE2 may advertise 661 VPWS AD route or LDP-LM message with proper PW-status message. 663 o The tunnel encapsulation attribute [RFC9012] is used to 664 synchronize alias PW label between peering PEs. The tunnel 665 encapsulation attribute, specifying the alias PW label and tunnel 666 endpoint (nexthop) of the remote PE (PE3), is transmitted along 667 with EVPN Ethernet-AD per EVI route. The NDF PEs uses the same 668 VPN label per L2VPN PW as DF PE when transmitting traffic coming 669 from CE (CE1) towards remote PE(PE3). 671 o Composite PE1 and PE2 do not need similar mechanism for EVPN-VPWS 672 since the same route advertised by PW is received on both PEs. 674 10. Route Optimization 676 With the simplest provisioning model, if a composite PE does not know 677 a priori whether the remote PE for a given P2P service is a L2VPN PE 678 or an EVPN PE, the composite needs to participate in the auto- 679 discovery and signaling procedures for both L2VPN and EVPN-VPWS. 680 This works well as it allows a composite to establish a P2P service 681 with different types of PEs composite PE, and to switch from using a 682 L2VPN PW to EVPN-VPWS dynamically during the migration process. 684 The simples provisioning model may not be optimal though, in that a 685 composite PE originates twice as many A-D routes as they are required 686 to establish the number of P2P services it is provisioned to. 687 Therefore in some scenario,a composite PE should be optimized to 688 perform either L2VPN or EVPN-VPWS procedure for a given P2P service, 689 but not both. 691 For a composite PE, if a Service Provider has prior knowledge about 692 the types of remote PEs for some or all of its P2P Ethernet services, 693 reducing the number of routes a composite PE originates can be 694 achieved through the configuration. Based on the configuration, a 695 composite may advertise EVPN route but not L2VPN A-D route for a P2P 696 Ethernet service, or vice versa. It is up to the Service Provider to 697 decide based on the network requirement. 699 11. IANA Considerations 701 This document has no actions for IANA. 703 12. Security Considerations 705 The same Security Considerations described in [RFC8214] are valid for 706 this document. 708 13. Acknowledgements 710 14. References 712 14.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, 716 DOI 10.17487/RFC2119, March 1997, 717 . 719 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 720 "Provisioning, Auto-Discovery, and Signaling in Layer 2 721 Virtual Private Networks (L2VPNs)", RFC 6074, 722 DOI 10.17487/RFC6074, January 2011, 723 . 725 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 726 Virtual Private Networks Using BGP for Auto-Discovery and 727 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 728 . 730 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 731 Maintenance Using the Label Distribution Protocol (LDP)", 732 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 733 . 735 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 736 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 737 May 2017, . 739 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 740 Rabadan, "Virtual Private Wire Service Support in Ethernet 741 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 742 . 744 14.2. Informative References 746 [I-D.ietf-bess-evpn-mh-pa] 747 Brissette, P., Sajassi, A., Burdet, L., Thoria, S., Wen, 748 B., Leyton, E., and J. Rabadan, "EVPN multi-homing port- 749 active load-balancing", draft-ietf-bess-evpn-mh-pa-03 750 (work in progress), July 2021. 752 [I-D.ietf-bess-evpn-vpws-fxc] 753 Sajassi, A., Brissette, P., Uttaro, J., Drake, J., 754 Boutros, S., and J. Rabadan, "EVPN VPWS Flexible Cross- 755 Connect Service", draft-ietf-bess-evpn-vpws-fxc-03 (work 756 in progress), June 2021. 758 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 759 2 Virtual Private Networks (L2VPNs)", RFC 4664, 760 DOI 10.17487/RFC4664, September 2006, 761 . 763 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 764 R., Patel, K., and J. Guichard, "Constrained Route 765 Distribution for Border Gateway Protocol/MultiProtocol 766 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 767 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 768 November 2006, . 770 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 771 LAN Service (VPLS) Using BGP for Auto-Discovery and 772 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 773 . 775 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 776 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 777 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 778 . 780 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 781 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 782 DOI 10.17487/RFC9012, April 2021, 783 . 785 Authors' Addresses 787 Patrice Brissette 788 Cisco Systems 790 Email: pbrisset@cisco.com 792 Ali Sajassi 793 Cisco Systems 795 Email: sajassi@cisco.com 797 Luc Andre Burdet 798 Cisco Systems 800 Email: lburdet@cisco.com 802 Wen Lin 803 Juniper 805 Email: wlin@juniper.com 806 J. Rabadan 807 Nokia 809 Email: jorge.rabadan@nokia.com 811 James Uttaro 812 ATT 814 Email: uttaro@att.com 816 Daniel Voyer 817 Bell Canada 819 Email: daniel.voyer@bell.ca 821 Iman Ghamari 822 Linkedin 824 Email: iman@linkedin.com 826 Edward Leyton 827 Verizon Wireless 829 Email: edward.leyton@verizonwireless.com 831 Bin Wen 832 Comcast 834 Email: bin_wen@comcast.com 836 Voitek Kozak 837 Comcast 839 Email: voitek_kozak@comcast.com