idnits 2.17.1 draft-brissette-bess-evpn-vpws-seamless-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (March 11, 2021) is 1114 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 Working Group P. Brissette, Ed. 3 Internet-Draft A. Sajassi 4 Intended status: Standards Track LA. Burdet 5 Expires: September 12, 2021 Cisco Systems 6 J. Uttaro 7 ATT 8 D. Voyer 9 Bell Canada 10 I. Ghamari 11 LinkedIn 12 E. Leyton 13 Verizon Wireless 14 March 11, 2021 16 EVPN-VPWS Seamless Integration with Legacy VPWS 17 draft-brissette-bess-evpn-vpws-seamless-02 19 Abstract 21 This document specifies mechanisms for backward compatibility of 22 Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) solutions with 23 legacy Virtual Private Wire Service (VPWS). It provides mechanisms 24 for seamless integration in the same MPLS/IP network on a per- 25 pseudowire or per flexible-crossconnect service basis. 26 Implementation of this document enables service providers to 27 introduce EVPN-VPWS PEs in their brown-field deployments of legacy 28 VPWS networks. This document specifies control-plane and forwarding 29 behaviour needed for auto-discovery of a pseudowire in order to 30 enable seamless integration between EVPN-VPWS and VPWS PEs. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 12, 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 68 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 69 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 6 70 4. Seamless Integration . . . . . . . . . . . . . . . . . . . . 7 71 5. Capability Discovery . . . . . . . . . . . . . . . . . . . . 7 72 6. Forwarding and Control Plane Operations . . . . . . . . . . . 7 73 6.1. Multi-homed Operations . . . . . . . . . . . . . . . . . 9 74 6.1.1. Operations with Port-Active MH PEs . . . . . . . . . 9 75 6.1.2. Operation with Single-Active MH PEs . . . . . . . . . 10 76 6.1.3. Operation with All-Active MH PEs . . . . . . . . . . 10 77 6.1.3.1. Falling back to port-active . . . . . . . . . . . 10 78 6.1.3.2. Asymmetric forwarding . . . . . . . . . . . . . . 11 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 Virtual Private Wire Service (VPWS) is a widely-deployed Layer-2 VPN 90 (L2VPN) technology. Many service providers, who are looking at 91 adopting Ethernet VPN Virtual Private Wire Service (EVPN-VPWS), want 92 to preserve their investment in the VPWS networks. Hence, they 93 require mechanisms by which EVPN-VPWS can be introduced into their 94 brown-field legacy VPWS networks without requiring any upgrades 95 (software or hardware) to these networks. This document specifies 96 control-plane and forwarding behaviour needed for auto-discovery of a 97 pseudowire in order to enable seamless integration between EVPN-VPWS 98 Provider Edge(PE) devices and PEs running legacy VPWS services in the 99 same MPLS/IP network. 101 MPLS/IP Core 102 +---------------+ 103 +---+ | | +---+ 104 |PE1|----|----- PW1 -----|---|PE2| Legacy VPWS 105 | |----|---+ | +---+ 106 +---+ | | | 107 EVPN-VPWS & | +--PW2---+ | +---+ 108 Legacy VPWS | +--|---|PE3| EVPN-VPWS 109 (hybrid) | | +---+ 110 +---------------+ 112 Seamless Integration of EVPN-VPWS. 114 Figure 1 116 Figure 1 shows a simple network where PE1 runs in hybrid mode (EVPN- 117 VPWS and legacy VPWS). It provides a pseudowire (PW1) with PE2 118 running legacy VPWS. It also provides a pseudowire (PW2) with PE3 119 running EVPN-VPWS. PE2 may be upgraded to EVPN-VPWS seamlessly. 120 Legacy PEs may be setting up PWs per [RFC8077] or may be setting up a 121 VPWS service by first auto-discovering VPN members using [RFC6074] 122 and then setting up the PWs using [RFC8077] or [RFC6624]. 124 The seamless integration solution described in this document has the 125 following attributes: 127 - It is backward compatible with [RFC8214] and EVPN Flexible 128 crossconnect Service [evpn_fxc] document. 130 - New PEs can leverage the multi-homing mechanisms and provisioning 131 simplifications of EVPN Ethernet-Segment: 133 a. Auto-sensing of MHN / MHD 135 b. Auto-discovery of redundancy group 137 c. Auto-election of Designated Forwarder and VLAN carving 139 d. Support of various load-balancing mode such as port-active, 140 single-active and all-active 142 Figure 2 illustrates how legacy VPWS brown-field network migration to 143 EVPN-VPWS is achieved. For example, let say PE1 and PE2 have a 144 legacy PW established between them. First, network operator may 145 upgrade PE2 to support EVPN-VPWS. Once upgraded, PE2 which now have 146 the EVPN-VPWS capability still runs legacy VPWS PW with PE1. Later 147 on, network operator may decide to upgrade PE1 to support EVPN-VPWS. 148 As soon as the upgrade is completed, EVPN-VPWS service takes high- 149 precedence over legacy VPWS network. The network operator can safely 150 remove any legacy configuration related to that PW from PE1 and PE2 151 nodes. PW remains established as an EVPN-VPWS service. 153 MPLS/IP Core 154 +---------------+ 155 +---+ | | +---+ 156 |PE1|----|----- PW1 -----|---|PE2| 157 +---+ | Legacy | +---+ 158 Legacy | | Legacy 159 VPWS +---------------+ VPWS 160 .... 161 +---------------+ 162 +---+ | | +---+ 163 |PE1|----|----- PW1 -----|---|PE2| 164 +---+ | Legacy | +---+ 165 Legacy | | Legacy VPWS 166 VPWS +---------------+ + EVPN-VPWS 167 .... 168 +---------------+ 169 +---+ | | +---+ 170 |PE1|----|----- PW1 -----|---|PE2| 171 +---+ | EVPN-VPWS | +---+ 172 Legacy VPWS | | Legacy VPWS 173 + EVPN-VPWS +---------------+ + EVPN-VPWS 174 .... 175 +---------------+ 176 +---+ | | +---+ 177 |PE1|----|----- PW1 -----|---|PE2| 178 +---+ | EVPN-VPWS | +---+ 179 EVPN-VPWS | | EVPN-VPWS 180 +---------------+ 182 Migration from Legacy to EVPN-VPWS. 184 Figure 2 186 1.1. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in [RFC2119]. 192 2. Terms and Abbreviations 194 o CE: A Customer Edge device, e.g., a host, router, or switch. 196 o DF: EVPN Ethernet Segment Designated Forwarder. 198 o NDF: EVPN Ethernet Segment Non-Designated Forwarder. 200 o Ethernet Segment (ES): Refers to the set of Ethernet links that 201 connects a customer site (device or network) to one or more PEs. 203 o Ethernet Tag: An Ethernet Tag identifies a particular pseudowire, 204 e.g. a PW-ID as per [RFC8214]. 206 o FEC: Forwarding Equivalence Class. 208 o LDP-LM: LDP Label Mapping Message. 210 o LDP-LW: LDP Label Withdraw Message. 212 o LSP: Label Switched Path. 214 o MHD: Multi-Homed Device. 216 o MHN: Multi-Homed Network. 218 o P2P: Point to Point - a P2P LSP typically refers to a LSP for 219 Layer2 pseudowire. 221 o PE: Provider Edge device. 223 o VPWS: Virtual Private Wire Service. It refers to legacy VPWS 224 circuit where pseudowires are signalled using LDP or BGP-AD 225 protocol. The latter is referred as VPWS A-D. 227 o EVPN-VPWS: Ethernet-VPN Virtual Private Wire Service. It refers 228 to EVPN-VPWS circuit where pseudowires are signalled via BGP-EVPN. 229 It can also refer to [evpn_fxc]. 231 o EVPN-FXC: Ethernet-VPN Flexible Cross-connect Service [evpn_fxc]. 233 o Port-Active Redundancy Mode: When only a single PE, among all the 234 PEs attached to an Ethernet segment, is allowed to forward traffic 235 to/from that Ethernet segment for a given interface, then the 236 Ethernet Segment is defined to be operating in Port-Active 237 redundancy mode. 239 o Single-Active Redundancy Mode: When only a single PE, among all 240 the PEs attached to an Ethernet segment, is allowed to forward 241 traffic to/from that Ethernet segment for a given VLAN, then the 242 Ethernet Segment is defined to be operating in Single-Active 243 redundancy mode. 245 o All-Active Redundancy Mode: When all PEs attached to an Ethernet 246 Segment are allowed to forward traffic to/from that Ethernet 247 segment for a given VLAN, then the Ethernet segment is defined to 248 be operating in All-Active redundancy mode. 250 o VPWS A-D: refers to Virtual Private Wire Services with BGP-based 251 Auto Discovery as in [RFC6074]. 253 o PW: Pseudowire 255 3. Solution Requirements 257 Following are the key requirements for backward compatibility between 258 EVPN-VPWS and VPWS: 260 o The solution MUST allow for staged migration towards EVPN-VPWS on 261 a site-by-site basis - e.g., new EVPN-VPWS sites to be provisioned 262 on EVPN-VPWS Provider Edge devices (PEs). Migration SHOULD be 263 possible on a per-pseudowire basis. 265 o The solution MUST NOT require any changes to existing Legacy VPWS 266 or PEs, unless it is to upgrade them to EVPN-VPWS. 268 o The solution MUST allow for the co-existence of PE devices running 269 EVPN-VPWS and VPWS for the same single-homed and/or multi-homed 270 segments. 272 o The solution MUST support port-active redundancy of multi-homed 273 networks and multi-homed devices for EVPN-VPWS PEs. 275 o The solution MUST support single-active redundancy of multi-homed 276 networks and multi-homed devices for EVPN-VPWS PEs. 278 o The solution SHOULD support all-active redundancy of multi-homed 279 Ethernet Segments for EVPN-VPWS PEs. 281 These requirements collectively allow for the seamless insertion of 282 the EVPN-VPWS technology into brown-field VPWS deployments. 284 4. Seamless Integration 286 In order to support seamless integration with Legacy PEs, this 287 document may require Legacy PEs to setup PWs per [RFC8077] or may 288 require Legacy PEs to setup VPWS service by auto-discovering VPN 289 members using [RFC6074] and then setting up the PWs using [RFC8077] 290 or [RFC6624]. Furthermore, EVPN-VPWS PEs must support BGP EVPN 291 routes per [RFC8214] and one of method of legacy VPWS technologies. 292 All the logic for seamless integration SHALL reside on the EVPN-VPWS 293 PEs. 295 5. Capability Discovery 297 The EVPN-VPWS PEs MUST advertise both BGP VPWS Auto-Discovery (VPWS 298 A-D) route or LDP-LM message as well as the BGP EVPN Ethernet-AD per 299 EVI route for a given pseudowire. 301 In the case of VPWS PEs running VPWS A-D, they may advertise the BGP 302 VPWS A-D route, per the procedures specified in [RFC4664] and 303 [RFC6074]. The operator may decide to use the same BGP Route Target 304 (RT) to identify a pseudowire on both EVPN-VPWS and VPWS networks. 305 In this case, when a VPWS PE receives the EVPN Ethernet-AD per EVI 306 route, it MUST ignore it on the basis that it belongs to an unknown 307 SAFI. However, the operator may choose to use two RTs - one to 308 identify the pseudowire on VPWS network and another for EVPN-VPWS 309 network and employ RT-constrained [RFC4684] in order to prevent BGP 310 EVPN routes from reaching the VPWS PEs. 312 When an EVPN-VPWS PE receives both a VPWS A-D route or a LDP-LM 313 message as well as an EVPN-VPWS Ethernet-AD per EVI route from a 314 given remote PE for the same pseudowire, it MUST give preference to 315 the EVPN-VPWS route for the purpose of discovery. This ensures that, 316 at the end of the route exchange, all EVPN-VPWS capable PEs discover 317 other EVPN-VPWS capable PEs. Furthermore, all the VPWS-only PEs 318 discover the EVPN-VPWS PEs as if they are standard VPWS PEs. In 319 other words, when the discovery phase is completed, the EVPN-VPWS PEs 320 have discovered the remote PE per pseudowire along with their 321 associated capability (EVPN-VPWS or VPWS-only), whereas the VPWS PE 322 have discovered the remote PE per pseudowire as if it is VPWS-only 323 PEs. 325 6. Forwarding and Control Plane Operations 327 Figure 3 demonstrates a typical brown-field deployment where PE2 is a 328 legacy PE and PE1 is an EVPN-VPWS PE. 330 EVPN-VPWS & MPLS/IP 331 Legacy VPWS Core Legacy VPWS 332 +---------------+ 333 +---+ | | +---+ 334 |PE1|----|----- PW1 -----|---|PE2| 335 +---+ | | +---+ 336 +---------------+ 338 VPWS A-D route ] TX TX [ VPWS A-D route 339 or ] ---> <--- [ or 340 LDP Label Mapping ] [ LDP Label Mapping 342 AND 343 TX 344 EVPN per EVI/EAD ] ---> 346 EVPN-VPWS Single-Homed 348 Figure 3 350 The forwarding state setup procedures over VPWS PEs are per 351 [RFC8077], [RFC4761] and [RFC4762]. 353 The EVPN-VPWS PE procedures are as follow: 355 o The EVPN-VPWS PE MUST establish a PW to each remote PE from which 356 it has received only a VPWS A-D route or a LDP-LM message for the 357 corresponding pseudowire, and MUST set up the label stack 358 corresponding to the PW FEC. 360 o If an EVPN-VPWS PE receives a VPWS A-D route or a LDP-LM message 361 from a given PE, it sets up a Legacy VPWS PW to that PE. If it 362 then receives an EVPN Ethernet-AD per EVI route for that PW from 363 the same PE, then the EVPN-VPWS PE may bring the Legacy PW 364 operationally down and MUST forward traffic using the label 365 information from the EVPN Ethernet-AD per EVI route. 367 o If an EVPN-VPWS PE receives an EVPN Ethernet-AD per EVI route 368 followed by a VPWS A-D route or a LDP-LM message from the same PE, 369 then the EVPN-VPWS PE will setup the EVPN-VPWS PW. It may keep 370 the Legacy VPWS PW operationally down and MUST forward traffic 371 using the reachability information from that EVPN Ethernet-AD per 372 EVI route. 374 o For VPWS PEs not using VPWS A-D or LDP signalling, the EVPN-VPWS 375 PEs need to be provisioned manually with PWs to those remote VPWS 376 PEs for each pseudowire. In that case, if an EVPN-VPWS PE 377 receives an EVPN Ethernet-AD per EVI route from a PE to which a PW 378 exists, it may keep VPWS PW operationally down and MUST forward 379 traffic using the reachability information from that EVPN 380 Ethernet-AD per EVI route. 382 6.1. Multi-homed Operations 384 Figure 4 below demonstrates multi-homing scenarios. CE1 is connected 385 to PE1 and PE2 where PE1 is the designated forwarder while PE2 is the 386 non designated forwarder. 388 EVPN-VPWS & MPLS/IP 389 Legacy VPWS Core Legacy VPWS 390 +---------+ 391 DF +---+ | | +---+ +---+ 392 +--|PE1|----|---------|---|PE3|---|CE2| 393 +---+/ +---+ | PW1 /| +---+ +---+ 394 |CE1| | / | 395 +---+\ +---+ | / | 396 +--|PE2|----|-----+ | 397 NDF +---+ | | 398 +---------+ 400 EVPN-VPWS Port-Active Redundancy 402 Figure 4 404 6.1.1. Operations with Port-Active MH PEs 406 In Figure 4, PE1 and PE2 are configured in port-active load-balancing 407 mode. Both PEs are advertising EVPN Ethernet-AD per ES route with 408 the single-active bit set as described in EVPN port-active document 409 [evpn_pa]. In this example PE1 is DF elected for the shared Ethernet 410 Segment identifier. 412 o Only PE1, as DF, advertises the VPWS A-D route or LDP-LM message 413 towards remote PE3. 415 o PE1 advertises the EVPN Ethernet-AD per EVI route for PW1 towards 416 remote PE3. The P-bit in L2 Attributes Extended Community is set 417 for PE1 as per [RFC8214]. The purpose is to have all required 418 EVPN-VPWS routes on remote PE so during an upgrade from Legacy 419 VPWS to EVPN-VPWS, those remote nodes are immediately upgraded. 421 o PE2, as NDF, only advertises its EVPN Ethernet AD per EVI route 422 corresponding to that same PW1. The B-bit in L2 Attributes 423 Extended Community is set for PE2 as per [RFC8214] 425 Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN 426 Ethernet Segment DF Election procedures described in [RFC8214] for 427 EVPN-VPWS. Furthermore, PE1 withdraws its VPWS A-D route or sends 428 LDP-LW message to remote PE3 to teardown the Legacy PW. Finally, PE2 429 advertises corresponding VPWS A-D route or LDP-LM message for that 430 PW1 and re-establish Legacy PW with new PE2 destination. 432 If PE3 is running 2-way pseudowire redundancy and PW-status is 433 enabled, PE2 may leverage the existence of standby/backup PW with 434 PE3. In this particular scenario, PE2 may advertise VPWS A-D route 435 or LDP-LM message along with PW-status message. 437 Once PE3 is upgraded and supports EVPN-VPWS, seamless integration 438 procedures are applied. Higher precedence of EVPN-VPWS over VPWS 439 allow all PEs to avoid the usage of legacy circuit. At that point in 440 time, non-preferred legacy VPWS protocols and configuration may be 441 removed from all PEs. 443 6.1.2. Operation with Single-Active MH PEs 445 Single-active operation is similar to Port-active load-balancing mode 446 described above but at the VLAN level instead being of at the port/ 447 interface level. 449 The main difference resides on the support of Legacy PW VC-type 4 vs 450 PW VC-Type 5 mode on the EVPN-VPWS PE as per [RFC4448]. While 451 services running in port-active load-balancing mode require raw mode, 452 services running single-active load-balancing mode use tagged mode. 454 6.1.3. Operation with All-Active MH PEs 456 In EVPN-VPWS all-active load-balancing mode, all PEs participating in 457 a redundancy group forward traffic bidirectionally, reducing the 458 importance of DF and NDF PE. However PEs running Legacy VPWS do NOT 459 support all-active peering PEs as remote endpoint. 461 6.1.3.1. Falling back to port-active 463 EVPN-VPWS PE discovering remote PE running VPWS PW MAY fallback into 464 port-active load-balancing mode. In that case, following rules are 465 applied: 467 o Peering PEs advertise EVPN Ethernet-AD per ES route with the 468 single-active bit set. They also advertise EVPN Ethernet-AD per 469 EVI route towards PE3 with P/B bit set accordingly as per 470 [RFC8214]. 472 o DF PE advertises VPWS AD routes or LDP-LM message and EVPN 473 Ethernet AD per EVI route per PW. 475 o NDF PE advertises only EVPN Ethernet AD per EVI route per PW. 477 o If PE3 is running 2-ways pseudowire redundancy, PE2 may leverage 478 the existence of standby/backup PW with PE3. PE2 may advertise 479 VPWS AD route or LDP-LM message with proper PW-status message. 481 6.1.3.2. Asymmetric forwarding 483 One privilege option is the asymmetric forwarding while peering PEs 484 run in all-active load-balancing mode. In the example of Figure 3, 485 traffic from CE1 going to PE1 is forwarded to PE3 using the VPN label 486 learned from VPWS AD route or LDP-LM message received from PE3. 487 Traffic from CE1 going to PE2 should get forwarded to PE3 using that 488 same VPN label. Traffic coming from CE3 to PE3 gets forwarded only 489 over the primary PW towards PE1; the DF PE. 491 Supporting asymmetric forwarding with purely LDP as per [RFC8077] 492 requires extensions to EVPN-VPWS MH procedures. These procedures are 493 NOT restricted only to LDP and may be applied to VPWS A-D. 495 Following rules are applied to achieve expected behaviour: 497 o Peering PEs advertise EVPN Ethernet-AD per ES route with the 498 single-active bit unset. That is to get the network ready when 499 remote legacy PE are upgraded to EVPN-VPWS. 501 o DF PE advertises VPWS AD routes or LDP-LM message and EVPN 502 Ethernet AD per EVI route per PW. 504 o NDF PE advertises only EVPN Ethernet AD per EVI route per PW. 506 o If PE3 is running 2-ways pseudowire redundancy, PE2 may leverage 507 the existence of standby/backup PW with PE3. PE2 may advertise 508 VPWS AD route or LDP-LM message with proper PW-status message. 510 o The tunnel encapsulation attribute [tun_encap] is used to 511 synchronize alias PW label between peering PEs. The tunnel 512 encapsulation attribute, specifying the alias PW label and tunnel 513 endpoint (nexthop) of the remote PE (PE3), is transmitted along 514 with EVPN Ethernet-AD per EVI route. The NDF PEs uses the same 515 VPN label per Legacy PW as DF PE when transmitting traffic coming 516 from CE (CE1) towards remote PE(PE3). 518 7. IANA Considerations 520 This document has no actions for IANA. 522 8. Security Considerations 524 The same Security Considerations described in [RFC8214] are valid for 525 this document. 527 9. Acknowledgements 529 The authors would like to acknowledge Sylvain Masse for his feedback 530 and contribution to this document. 532 10. References 534 10.1. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, 538 DOI 10.17487/RFC2119, March 1997, 539 . 541 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 542 "Provisioning, Auto-Discovery, and Signaling in Layer 2 543 Virtual Private Networks (L2VPNs)", RFC 6074, 544 DOI 10.17487/RFC6074, January 2011, 545 . 547 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 548 Virtual Private Networks Using BGP for Auto-Discovery and 549 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 550 . 552 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 553 Maintenance Using the Label Distribution Protocol (LDP)", 554 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 555 . 557 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 558 Rabadan, "Virtual Private Wire Service Support in Ethernet 559 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 560 . 562 10.2. Informative References 564 [evpn_fxc] 565 Sajassi, A. and P. Brissette, "draft-ietf-bess-evpn-vpws- 566 fxc", 2019. 568 [evpn_pa] Brissette, P. and A. Sajassi, "draft-brissette-bess-evpn- 569 mh-pa", 2019. 571 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 572 "Encapsulation Methods for Transport of Ethernet over MPLS 573 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 574 . 576 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 577 2 Virtual Private Networks (L2VPNs)", RFC 4664, 578 DOI 10.17487/RFC4664, September 2006, 579 . 581 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 582 R., Patel, K., and J. Guichard, "Constrained Route 583 Distribution for Border Gateway Protocol/MultiProtocol 584 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 585 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 586 November 2006, . 588 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 589 LAN Service (VPLS) Using BGP for Auto-Discovery and 590 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 591 . 593 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 594 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 595 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 596 . 598 [tun_encap] 599 Patel, K., Van de Velde, G., and S. Sangli, "draft-ietf- 600 idr-tunnel-encaps", 2019. 602 [vpls_AA] Sajassi, A., Salam, S., Brissette, P., and L. Jalil, 603 "draft-sajassi-bess-evpn-vpls-all-active", 2017. 605 Authors' Addresses 606 Patrice Brissette (editor) 607 Cisco Systems 608 Ottawa, ON 609 Canada 611 Email: pbrisset@cisco.com 613 Ali Sajassi 614 Cisco Systems 615 USA 617 Email: sajassi@cisco.com 619 Luc Andre Burdet 620 Cisco Systems 621 Ottawa, ON 622 Canada 624 Email: lburdet@cisco.com 626 James Uttaro 627 ATT 628 USA 630 Email: uttaro@att.com 632 Daniel Voyer 633 Bell Canada 634 Montreal, QC 635 Canada 637 Email: daniel.voyer@bell.ca 639 Iman Ghamari 640 LinkedIn 641 USA 643 Email: ighamari@linkedin.com 644 Edward Leyton 645 Verizon Wireless 646 USA 648 Email: edward.leyton@verizonwireless.com