idnits 2.17.1 draft-brissette-bess-vpws-seamless-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 (October 31, 2019) is 1636 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 L. Burdet 5 Expires: May 3, 2020 Cisco Systems 6 J. Uttaro 7 ATT 8 October 31, 2019 10 EVPN-VPWS Seamless Integration with Legacy VPWS 11 draft-brissette-bess-vpws-seamless-00 13 Abstract 15 This document specifies mechanisms for backward compatibility of 16 Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) solutions with 17 legacy Virtual Private Wire Service (VPWS). It provides mechanisms 18 for seamless integration in the same MPLS/IP network on a per- 19 pseudowire or per-flexible-crossconnect basis. Implementation of 20 this document enables service providers to introduce EVPN-VPWS PEs in 21 their brown-field deployments of leagcy VPWS networks. This document 22 specifies control-plane and forwarding behavior needed for auto- 23 discovery of a pseudowire in order to enable seamless integration 24 between EVPN-VPWS and VPWS PEs. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 3, 2020. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 62 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 63 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 5 64 4. Seamless Integration . . . . . . . . . . . . . . . . . . . . 6 65 5. Capability Discovery . . . . . . . . . . . . . . . . . . . . 6 66 6. Forwarding and Control Plane Operations . . . . . . . . . . . 6 67 6.1. Multi-homed Operations . . . . . . . . . . . . . . . . . 8 68 6.1.1. Operations with Port-Active MH PEs . . . . . . . . . 8 69 6.1.2. Operation with Single-Active MH PEs . . . . . . . . . 9 70 6.1.3. Operation with All-Active MH PEs . . . . . . . . . . 9 71 6.1.3.1. Falling back to port-active . . . . . . . . . . . 9 72 6.1.3.2. All-active procedures . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 77 9.2. Informative References . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 Virtual Private Wire Service (VPWS) is a widely-deployed Layer-2 VPN 83 (L2VPN) technology. Many service providers, who are looking at 84 adopting Ethernet VPN Virtual Private Wire Service (EVPN-VPWS), want 85 to preserve their investment in the VPWS networks. Hence, they 86 require mechanisms by which EVPN-VPWS can be introduced into their 87 brown-field legacy VPWS networks without requiring any upgrades 88 (software or hardware) to these networks. This document specifies 89 procedures for the seamless integration of the two technologies 90 (EVPN-VPWS and legacy VPWS) in the same MPLS/IP network. This 91 document specifies control-plane and forwarding behaviour needed for 92 auto-discovery of a pseudowire in order to enable seamless 93 integration between EVPN-VPWS Provider Edge(PE) devices and PEs 94 running legacy VPWS services. 96 MPLS/IP Core 97 +---------------+ 98 +---+ | | +---+ 99 |PE1|----|----- PW1 -----|---|PE2| Legacy VPWS 100 | |----|---+ | +---+ 101 +---+ | | | 102 EVPN-VPWS & | +--PW2---+ | +---+ 103 Legacy VPWS | +--|---|PE3| EVPN-VPWS 104 | | +---+ 105 +---------------+ 107 Seamless Integration of EVPN-VPWS. 109 Figure 1 111 Figure 1 shows a simple network where PE1 runs in hybrid mode (EVPN- 112 VPWS and legacy VPWS). It provides a pseudowire (PW1) with PE2 113 running legacy VPWS. It also provides a pseudowire (PW2) with PE2 114 running EVPN-VPWS. PE2 may be upgraded to EVPN-VPWS seamlessly. 115 Legacy PEs may be setting up PWs per [RFC8077] or may be setting up a 116 VPWS service by first auto-discovering VPN members using [RFC6074] 117 and then setting up the PWs using [RFC8077] or [RFC6624].\ 119 The seamless integration solution described in this document has the 120 following attributes: 122 - It is backward compatible with [RFC8214] and EVPN Flexible 123 crossconnect Service [evpn_fxc] document. 125 - New PEs can leverage the multi-homing mechanisms and provisioning 126 simplifications of EVPN Ethernet-Segment: 128 a. Auto-sensing of MHN / MHD 130 b. Auto-discovery of redundancy group 132 c. Auto-election of Designated Forwarder and VLAN carving 134 d. Support of various load-balancing mode such as port-active, 135 single-active and all-active 137 1.1. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 2. Terms and Abbreviations 145 o CE: A Customer Edge device, e.g., a host, router, or switch. 147 o DF: EVPN Ethernet Segment Designated Forwarder. 149 o NDF: EVPN Ethernet Segment Non-Designated Forwarder. 151 o Ethernet Segment (ES): Refers to the set of Ethernet links that 152 connects a customer site (device or network) to one or more PEs. 154 o Ethernet Tag: An Ethernet Tag identifies a particular pseudowire, 155 e.g. a PW-ID. 157 o FEC: Forwarding Equivalence Class 159 o LDP-LM: LDP Label Mapping Message 161 o LDP-LW: LDP Label Withdraw Message 163 o LSP: Label Switched Path 165 o MHD: Multi-Homed Device 167 o MHN: Multi-Homed Network 169 o P2P: Point to Point - a P2P LSP typically refers to a LSP for 170 Layer2 pseudowire 172 o PE: Provider Edge device 174 o VPWS: Virtual Private Wire Service. It refers to legacy VPWS 175 circuit where pseudowires are signalled using LDP or BGP-AD 176 protocol. The latter is referred as VPWS A-D. 178 o EVPN-VPWS: Ethernet-VPN Virtual Private Wire Service. It refers 179 to EVPN-VPWS circuit where pseudowires are signalled via BGP-EVPN. 180 It also includes EVPN-FXC service. 182 o EVPN-FXC: Ethernet-VPN Flexible Cross-connect Service [evpn_fxc]. 184 o Port-Active Redundancy Mode: When only a single PE, among all the 185 PEs attached to an Ethernet segment, is allowed to forward traffic 186 to/from that Ethernet segment for a given interface, then the 187 Ethernet Segment is defined to be operating in Port-Active 188 redundancy mode. 190 o Single-Active Redundancy Mode: When only a single PE, among all 191 the PEs attached to an Ethernet segment, is allowed to forward 192 traffic to/from that Ethernet segment for a given VLAN, then the 193 Ethernet Segment is defined to be operating in Single-Active 194 redundancy mode. 196 o All-Active Redundancy Mode: When all PEs attached to an Ethernet 197 Segment are allowed to forward traffic to/from that Ethernet 198 segment for a given VLAN, then the Ethernet segment is defined to 199 be operating in All-Active redundancy mode. 201 o VPWS A-D: refers to Virtual Private Wire Services with BGP-based 202 Auto Discovery as in [RFC6074]. 204 o PW: Pseudowire 206 3. Solution Requirements 208 o Following are the key requirements for backward compatibility 209 between EVPN-VPWS and VPWS: 211 o The solution MUST allow for staged migration towards EVPN-VPWS on 212 a site-by-site basis - e.g., new EVPN-VPWS sites to be provisioned 213 on EVPN-VPWS Provider Edge devices (PEs). Migration SHOULD be 214 possible on a per-pseudowire basis. 216 o The solution MUST NOT require any changes to existing VPWS or PEs, 217 not even a software upgrade. 219 o The solution MUST allow for the co-existence of PE devices running 220 EVPN-VPWS and VPWS for the same pseudowire and single-homed 221 segments. 223 o The solution MUST support port-active redundancy of multi-homed 224 networks and multi-homed devices for EVPN-VPWS PEs. 226 o The solution MUST support single-active redundancy of multi-homed 227 networks and multi-homed devices for EVPN-VPWS PEs. 229 o The solution SHOULD support all-active redundancy of multi-homed 230 Ethernet Segments for EVPN-VPWS PEs. 232 These requirements collectively allow for the seamless insertion of 233 the EVPN-VPWS technology into brown-field VPWS deployments. 235 4. Seamless Integration 237 In order to support seamless integration with Legacy PEs, this 238 document may require Legacy PEs to setup PWs per [RFC8077] or may 239 require Legacy PEs to setup VPWS service by auto-discovering VPN 240 members using [RFC6074] and then setting up the PWs using [RFC8077] 241 or [RFC6624]. Furthermore, EVPN-VPWS PEs must support BGP EVPN 242 routes per [RFC8214] and one of method of legacy VPWS technologies. 243 All the logic for seamless integration SHALL reside on the EVPN-VPWS 244 PEs. 246 5. Capability Discovery 248 The EVPN-VPWS PEs MUST advertise both the BGP VPWS Auto-Discovery 249 (VPWS A-D) route or LDP-LM message as well as the BGP EVPN Ethernet- 250 AD per EVI route for a given pseudowire. The VPWS PEs only advertise 251 the BGP VPWS A-D route, per the procedures specified in [RFC4664] and 252 [RFC6074]. The operator may decide to use the same BGP Route Target 253 (RT) to identify a pseudowire on both EVPN-VPWS and VPWS networks. 254 In this case, when a VPWS PE receives the EVPN Ethernet-AD per EVI 255 route, it MUST ignore it on the basis that it belongs to an unknown 256 SAFI. However, the operator may choose to use two RTs - one to 257 identify the pseudowire on VPWS network and another for EVPN-VPWS 258 network and employ RT-constrained [RFC4684] in order to prevent BGP 259 EVPN routes from reaching the VPWS PEs. 261 When an EVPN-VPWS PE receives both a VPWS A-D route or a LDP-LM 262 message as well as an EVPN-VPWS Ethernet-AD per EVI route from a 263 given remote PE for the same pseudowire, it MUST give preference to 264 the EVPN-VPWS route for the purpose of discovery. This ensures that, 265 at the end of the route exchanges, all EVPN-VPWS capable PEs discover 266 other EVPN-VPWS capable PEs. Furthermore, all the VPWS-only PEs will 267 discover the EVPN-VPWS PEs as if they were standard VPWS PEs. In 268 other words, when the discovery phase is complete, the EVPN-VPWS PEs 269 will have discovered the remote PE per pseudowire along with their 270 associated capability (EVPN-VPWS or VPWS-only), whereas the VPWS PE 271 will have discovered the remote PE per pseudowire as if it was VPWS- 272 only PEs. 274 6. Forwarding and Control Plane Operations 276 The procedures for forwarding state setup on the VPWS PE are per 277 [RFC8077], [RFC4761] and [RFC4762]. 279 EVPN-VPWS & MPLS/IP 280 Legacy VPWS Core Legacy VPWS 281 +---------------+ 282 +---+ | | +---+ 283 |PE1|----|----- PW1 -----|---|PE2| Legacy VPWS 284 +---+ | | +---+ 285 +---------------+ 287 VPWS A-D route ] TX TX [ VPWS A-D route 288 or ] ---> <--- [ or 289 LDP Label Mapping ] [ LDP Label Mapping 291 AND 292 TX 293 EVPN per EVI/EAD ] ---> 295 EVPN-VPWS Single-Homed 297 Figure 2 299 The procedures for forwarding state setup on the EVPN-VPWS PE are as 300 follows: 302 o The EVPN-VPWS PE MUST establish a PW to each remote PE from which 303 it has received only a VPWS A-D route or a LDP-LM message for the 304 corresponding pseudowire, and MUST set up the label stack 305 corresponding to the PW FEC. 307 o If an EVPN-VPWS PE receives a VPWS A-D route or a LDP-LM message 308 from a given PE, it sets up a Legacy VPWS PW to that PE. If it 309 then receives an EVPN Ethernet-AD per EVI route for that PW from 310 the same PE, then the EVPN-VPWS PE may bring the Legacy PW 311 operationally down and MUST forward traffic using the label 312 information from the EVPN Ethernet-AD per EVI route. 314 o If an EVPN-VPWS PE receives an EVPN Ethernet-AD per EVI route 315 followed by a VPWS A-D route or a LDP-LM message from the same PE, 316 then the EVPN-VPWS PE will setup the EVPN-VPWS PW. It may keep 317 the Legacy VPWS PW operationally down and MUST forward traffic 318 using the label information from that EVPN Ethernet-AD per EVI 319 route. 321 o For VPWS PE not using VPWS A-D or LDP signalling, the EVPN-VPWS 322 PEs need to be provisioned manually with PWs to those remote VPWS 323 PEs for each pseudowire. In that case, if an EVPN-VPWS PE 324 receives an EVPN Ethernet-AD per EVI route from a PE to which a PW 325 exists, it may keep VPWS PW operationally down and MUST forward 326 traffic using the label information from that EVPN Ethernet-AD per 327 EVI route. 329 6.1. Multi-homed Operations 331 Figure 3 below demonstrates multi-homing scenarios. CE1 is connected 332 to PE1 and PE2 where PE1 is the designated forwarder while PE2 is the 333 non designated forwarder. 335 EVPN-VPWS & MPLS/IP 336 Legacy VPWS Core Legacy VPWS 337 +---------+ 338 DF +---+ | | +---+ +---+ 339 +--|PE1|----|---------|---|PE3|---|CE2| 340 +---+/ +---+ | PW1 /| +---+ +---+ 341 |CE1| | / | 342 +---+\ +---+ | / | 343 +--|PE2|----|-----+ | 344 NDF +---+ | | 345 +---------+ 347 EVPN-VPWS Port-Active Redundancy 349 Figure 3 351 6.1.1. Operations with Port-Active MH PEs 353 In Figure 3, PE1 and PE2 are configured in port-active load-balancing 354 mode. Both PEs are advertising EVPN Ethernet-AD per ES route with 355 the single-active bit set as described in EVPN port-active document 356 [evpn_pa]. In this example PE1 is DF elected for the shared Ethernet 357 Segment identifier. 359 o Only PE1, as DF, advertises the VPWS A-D route or LDP-LM message 360 towards remote PE3. 362 o PE1 advertises the EVPN Ethernet AD per EVI route for PW1 towards 363 remote PE3. The P-bit in L2 Attributes Extended Community is set 364 for PE1 as per [RFC8214]. The purpose is to have all required 365 EVPN-VPWS routes on remote PE so during an upgrade from Legacy 366 VPWS to EVPN-VPWS, those remote nodes are immediately upgraded. 368 o PE2, as NDF, only advertises its EVPN Ethernet AD per EVI route 369 corresponding to that same PW1. The B-bit in L2 Attributes 370 Extended Community is set for PE1 as per [RFC8214] 372 Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN 373 Ethernet Segment DF Election and/or procedures described in [RFC8214] 374 for the EVPN-VPWS. Furthermore, PE1 withdraws its VPWS A-D route or 375 sends LDP-LW message to remote PE3 to teardown the Legacy PW. 376 Finally, PE2 advertises corresponding VPWS A-D route or LDP-LM 377 message for that PW1 and re-establish Legacy PW with new PE2 378 destination. 380 If PE3 is running 2-way pseudowire redundancy and PW-status is 381 enabled, PE2 may leverage the existance of standby/backup PW with 382 PE3. In this particular scenario where PW-status is enabled, PE2 may 383 advertise VPWS A-D route or LDP-LM message along with PW-status 384 message. 386 Once PE3 is upgraded and supports EVPN-VPWS, EVPN-VPWS routes are 387 exchanged by this PE. Higher precedence of EVPN-VPWS over VPWS allow 388 all PEs to avoid the usage of legacy circuit. At that point in time, 389 unpreferred legacy VPWS protocols and configuration may be removed 390 from all PEs. 392 6.1.2. Operation with Single-Active MH PEs 394 Single-active operation is similar to Port-active load-balancing mode 395 described above but at the VLAN level instead being of at the port/ 396 interface level. Moreover, the procedures described in [RFC8214] are 397 applied. 399 The main difference resides on the support of Legacy PW VC-type 4 vs 400 PW VC-Type 5 mode on the EVPN-VPWS PE as per [RFC4448]. While 401 services running in port-active load-balancing mode require raw mode, 402 services running single-active load-balancing mode use tagged mode. 404 6.1.3. Operation with All-Active MH PEs 406 In EVPN-VPWS all-active load-balancing mode, all PEs participating in 407 a redundancy group forward traffic bidirectionally, reducing the 408 importance of DF and NDF PE. However PEs running Legacy VPWS do NOT 409 support all-active peering PEs as remote endpoint. 411 6.1.3.1. Falling back to port-active 413 PE discovering remote PE running VPWS PW MAY fallback into port- 414 active load-balancing mode. In that case, following rules are 415 applied 417 o Peering PEs advertises EVPN Ethernet-AD per ES route with the 418 single-active bit set. 420 o DF PE advertises VPWS AD routes or LDP-LM message and EVPN 421 Ethernet AD per EVI route per PW. 423 o NDF PE advertises only EVPN Ethernet AD per EVI route per PW. 425 o If PE3 is running 2-ways pseudowire redundancy, PE2 may leverage 426 the existence of standby/backup PW with PE3. PE2 may advertises 427 VPWS AD route or LDP-LM message with proper PW-status message. 429 6.1.3.2. All-active procedures 431 To support the case where CE device is forwarding traffic to peering 432 PE, extensions to EVPN-VPWS MH procedure are required. In the 433 example of Figure 3, traffic from CE1 going to PE1 gets forwarded to 434 PE3 using the VPN label learned from VPWS AD route or LDP-LM message 435 received from PE3. Traffic from CE1 going to PE2 should gets 436 forwarded to PE3 using that same VPN label. Traffic coming from CE3 437 to PE3 gets forwarded only over the primary PW towards PE1. It is an 438 asymmetric forwarding. 440 Following rules are applied to achieve expected behaviour: 442 o Peering PEs advertises EVPN Ethernet-AD per ES route with the 443 single-active bit unset. Again, to this to get ready on remote PE 444 in case of that legacy PE gets upgraded to EVPN-VPWS. 446 o DF PE advertises VPWS AD routes or LDP-LM message and EVPN 447 Ethernet AD per EVI route per PW. 449 o NDF PE advertises only EVPN Ethernet AD per EVI route per PW. 451 o If PE3 is running 2-ways pseudowire redundancy, PE2 may leverage 452 the existence of standby/backup PW with PE3. PE2 may advertises 453 VPWS AD route or LDP-LM message with proper PW-status message. 455 To support all-active load-balancing mode on EVPN-VPWS peering PEs, 456 the tunnel encapsulation attribute [tun_encap] is used to synchronize 457 alias PW label between peering PEs. The tunnel encapsulation 458 attribute, specifying the alias PW label and tunnel endpoint 459 (nexthop) of the remote PE (PE3), is transmitted along with EVPN 460 Ethernet-AD per EVI route. The NDF PEs uses the same VPN label per 461 Legacy PW as DF PE when transmitting traffic coming from CE (CE1) 462 towards remote PE(PE3). 464 7. IANA Considerations 466 This document has no actions for IANA. 468 8. Security Considerations 470 The same Security Considerations described in RFC 8214 [RFC8214] are 471 valid for this document. 473 9. References 475 9.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 483 "Provisioning, Auto-Discovery, and Signaling in Layer 2 484 Virtual Private Networks (L2VPNs)", RFC 6074, 485 DOI 10.17487/RFC6074, January 2011, 486 . 488 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 489 Virtual Private Networks Using BGP for Auto-Discovery and 490 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 491 . 493 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 494 Maintenance Using the Label Distribution Protocol (LDP)", 495 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 496 . 498 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 499 Rabadan, "Virtual Private Wire Service Support in Ethernet 500 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 501 . 503 9.2. Informative References 505 [evpn_fxc] 506 Sajassi, A. and P. Brissette, "draft-ietf-bess-evpn-vpws- 507 fxc", 2019. 509 [evpn_pa] Brissette, P. and A. Sajassi, "draft-brissette-bess-evpn- 510 mh-pa", 2019. 512 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 513 "Encapsulation Methods for Transport of Ethernet over MPLS 514 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 515 . 517 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 518 2 Virtual Private Networks (L2VPNs)", RFC 4664, 519 DOI 10.17487/RFC4664, September 2006, 520 . 522 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 523 R., Patel, K., and J. Guichard, "Constrained Route 524 Distribution for Border Gateway Protocol/MultiProtocol 525 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 526 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 527 November 2006, . 529 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 530 LAN Service (VPLS) Using BGP for Auto-Discovery and 531 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 532 . 534 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 535 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 536 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 537 . 539 [tun_encap] 540 Patel, K., Van de Velde, G., and S. Sangli, "draft-ietf- 541 idr-tunnel-encaps", 2019. 543 [vpls_AA] Sajassi, A., Salam, S., Brissette, P., and L. Jalil, 544 "draft-sajassi-bess-evpn-vpls-all-active", 2017. 546 Authors' Addresses 548 Patrice Brissette (editor) 549 Cisco Systems 550 Ottawa, ON 551 Canada 553 Email: pbrisset@cisco.com 554 Ali Sajassi 555 Cisco Systems 556 USA 558 Email: sajassi@cisco.com 560 Luc Andre Burdet 561 Cisco Systems 562 Ottawa 563 Canada 565 Email: lburdet@cisco.com 567 James Uttaro 568 ATT 569 USA 571 Email: uttaro@att.com