idnits 2.17.1 draft-brissette-bess-evpn-vpws-seamless-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 18, 2019) is 1614 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 21, 2020 Cisco Systems 6 J. Uttaro 7 ATT 8 D. Voyer 9 Bell Canada 10 I. Ghamari 11 Telus 12 E. Leyton 13 Verizon Wireless 14 November 18, 2019 16 EVPN-VPWS Seamless Integration with Legacy VPWS 17 draft-brissette-bess-evpn-vpws-seamless-01 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 May 21, 2020. 49 Copyright Notice 51 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . 4 69 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 5 70 4. Seamless Integration . . . . . . . . . . . . . . . . . . . . 6 71 5. Capability Discovery . . . . . . . . . . . . . . . . . . . . 6 72 6. Forwarding and Control Plane Operations . . . . . . . . . . . 7 73 6.1. Multi-homed Operations . . . . . . . . . . . . . . . . . 8 74 6.1.1. Operations with Port-Active MH PEs . . . . . . . . . 8 75 6.1.2. Operation with Single-Active MH PEs . . . . . . . . . 9 76 6.1.3. Operation with All-Active MH PEs . . . . . . . . . . 9 77 6.1.3.1. Falling back to port-active . . . . . . . . . . . 10 78 6.1.3.2. Asymmetric forwarding . . . . . . . . . . . . . . 10 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 81 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 84 10.2. Informative References . . . . . . . . . . . . . . . . . 12 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 One of the objective of this document is to describe how a legacy 143 VPWS brown-field network can be migrated seamless to EVPN-VPWS. 145 Usually, it is achieved in few steps. For example, let say PE1 and 146 PE2 from Figure 1 have a legacy PW established between them. First, 147 network operator may upgrade PE1 to support EVPN-VPWS. Once 148 upgraded, PE1 which now have the EVPN-VPWS capability still runs 149 legacy VPWS PW with PE2. Later on, network operator may decide to 150 upgrade PE2 to support EVPN-VPWS. As soon as the upgrade is 151 completed, EVPN-VPWS service takes high-precedence over legacy VPWS 152 network. The network operator can safely remove any legacy 153 configuration related to that PW from PE1 and PE2 nodes. PW remains 154 established as an EVPN-VPWS service. 156 1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 2. Terms and Abbreviations 164 o CE: A Customer Edge device, e.g., a host, router, or switch. 166 o DF: EVPN Ethernet Segment Designated Forwarder. 168 o NDF: EVPN Ethernet Segment Non-Designated Forwarder. 170 o Ethernet Segment (ES): Refers to the set of Ethernet links that 171 connects a customer site (device or network) to one or more PEs. 173 o Ethernet Tag: An Ethernet Tag identifies a particular pseudowire, 174 e.g. a PW-ID as per [RFC8214]. 176 o FEC: Forwarding Equivalence Class. 178 o LDP-LM: LDP Label Mapping Message. 180 o LDP-LW: LDP Label Withdraw Message. 182 o LSP: Label Switched Path. 184 o MHD: Multi-Homed Device. 186 o MHN: Multi-Homed Network. 188 o P2P: Point to Point - a P2P LSP typically refers to a LSP for 189 Layer2 pseudowire. 191 o PE: Provider Edge device. 193 o VPWS: Virtual Private Wire Service. It refers to legacy VPWS 194 circuit where pseudowires are signalled using LDP or BGP-AD 195 protocol. The latter is referred as VPWS A-D. 197 o EVPN-VPWS: Ethernet-VPN Virtual Private Wire Service. It refers 198 to EVPN-VPWS circuit where pseudowires are signalled via BGP-EVPN. 199 It can also refer to [evpn_fxc]. 201 o EVPN-FXC: Ethernet-VPN Flexible Cross-connect Service [evpn_fxc]. 203 o Port-Active Redundancy Mode: When only a single PE, among all the 204 PEs attached to an Ethernet segment, is allowed to forward traffic 205 to/from that Ethernet segment for a given interface, then the 206 Ethernet Segment is defined to be operating in Port-Active 207 redundancy mode. 209 o Single-Active Redundancy Mode: When only a single PE, among all 210 the PEs attached to an Ethernet segment, is allowed to forward 211 traffic to/from that Ethernet segment for a given VLAN, then the 212 Ethernet Segment is defined to be operating in Single-Active 213 redundancy mode. 215 o All-Active Redundancy Mode: When all PEs attached to an Ethernet 216 Segment are allowed to forward traffic to/from that Ethernet 217 segment for a given VLAN, then the Ethernet segment is defined to 218 be operating in All-Active redundancy mode. 220 o VPWS A-D: refers to Virtual Private Wire Services with BGP-based 221 Auto Discovery as in [RFC6074]. 223 o PW: Pseudowire 225 3. Solution Requirements 227 Following are the key requirements for backward compatibility between 228 EVPN-VPWS and VPWS: 230 o The solution MUST allow for staged migration towards EVPN-VPWS on 231 a site-by-site basis - e.g., new EVPN-VPWS sites to be provisioned 232 on EVPN-VPWS Provider Edge devices (PEs). Migration SHOULD be 233 possible on a per-pseudowire basis. 235 o The solution MUST NOT require any changes to existing Legacy VPWS 236 or PEs, unless it is to upgrade them to EVPN-VPWS. 238 o The solution MUST allow for the co-existence of PE devices running 239 EVPN-VPWS and VPWS for the same single-homed and/or multi-homed 240 segments. 242 o The solution MUST support port-active redundancy of multi-homed 243 networks and multi-homed devices for EVPN-VPWS PEs. 245 o The solution MUST support single-active redundancy of multi-homed 246 networks and multi-homed devices for EVPN-VPWS PEs. 248 o The solution SHOULD support all-active redundancy of multi-homed 249 Ethernet Segments for EVPN-VPWS PEs. 251 These requirements collectively allow for the seamless insertion of 252 the EVPN-VPWS technology into brown-field VPWS deployments. 254 4. Seamless Integration 256 In order to support seamless integration with Legacy PEs, this 257 document may require Legacy PEs to setup PWs per [RFC8077] or may 258 require Legacy PEs to setup VPWS service by auto-discovering VPN 259 members using [RFC6074] and then setting up the PWs using [RFC8077] 260 or [RFC6624]. Furthermore, EVPN-VPWS PEs must support BGP EVPN 261 routes per [RFC8214] and one of method of legacy VPWS technologies. 262 All the logic for seamless integration SHALL reside on the EVPN-VPWS 263 PEs. 265 5. Capability Discovery 267 The EVPN-VPWS PEs MUST advertise both BGP VPWS Auto-Discovery (VPWS 268 A-D) route or LDP-LM message as well as the BGP EVPN Ethernet-AD per 269 EVI route for a given pseudowire. 271 In the case of VPWS PEs running VPWS A-D, they may advertise the BGP 272 VPWS A-D route, per the procedures specified in [RFC4664] and 273 [RFC6074]. The operator may decide to use the same BGP Route Target 274 (RT) to identify a pseudowire on both EVPN-VPWS and VPWS networks. 275 In this case, when a VPWS PE receives the EVPN Ethernet-AD per EVI 276 route, it MUST ignore it on the basis that it belongs to an unknown 277 SAFI. However, the operator may choose to use two RTs - one to 278 identify the pseudowire on VPWS network and another for EVPN-VPWS 279 network and employ RT-constrained [RFC4684] in order to prevent BGP 280 EVPN routes from reaching the VPWS PEs. 282 When an EVPN-VPWS PE receives both a VPWS A-D route or a LDP-LM 283 message as well as an EVPN-VPWS Ethernet-AD per EVI route from a 284 given remote PE for the same pseudowire, it MUST give preference to 285 the EVPN-VPWS route for the purpose of discovery. This ensures that, 286 at the end of the route exchange, all EVPN-VPWS capable PEs discover 287 other EVPN-VPWS capable PEs. Furthermore, all the VPWS-only PEs 288 discover the EVPN-VPWS PEs as if they are standard VPWS PEs. In 289 other words, when the discovery phase is completed, the EVPN-VPWS PEs 290 have discovered the remote PE per pseudowire along with their 291 associated capability (EVPN-VPWS or VPWS-only), whereas the VPWS PE 292 have discovered the remote PE per pseudowire as if it is VPWS-only 293 PEs. 295 6. Forwarding and Control Plane Operations 297 Figure 2 demonstrates a typical brown-field deployment where PE2 is a 298 legacy PE and PE1 is an EVPN-VPWS PE. 300 EVPN-VPWS & MPLS/IP 301 Legacy VPWS Core Legacy VPWS 302 +---------------+ 303 +---+ | | +---+ 304 |PE1|----|----- PW1 -----|---|PE2| 305 +---+ | | +---+ 306 +---------------+ 308 VPWS A-D route ] TX TX [ VPWS A-D route 309 or ] ---> <--- [ or 310 LDP Label Mapping ] [ LDP Label Mapping 312 AND 313 TX 314 EVPN per EVI/EAD ] ---> 316 EVPN-VPWS Single-Homed 318 Figure 2 320 The forwarding state setup procedures on the VPWS PE are per 321 [RFC8077], [RFC4761] and [RFC4762]. 323 The EVPN-VPWS PE procedures are as follow: 325 o The EVPN-VPWS PE MUST establish a PW to each remote PE from which 326 it has received only a VPWS A-D route or a LDP-LM message for the 327 corresponding pseudowire, and MUST set up the label stack 328 corresponding to the PW FEC. 330 o If an EVPN-VPWS PE receives a VPWS A-D route or a LDP-LM message 331 from a given PE, it sets up a Legacy VPWS PW to that PE. If it 332 then receives an EVPN Ethernet-AD per EVI route for that PW from 333 the same PE, then the EVPN-VPWS PE may bring the Legacy PW 334 operationally down and MUST forward traffic using the label 335 information from the EVPN Ethernet-AD per EVI route. 337 o If an EVPN-VPWS PE receives an EVPN Ethernet-AD per EVI route 338 followed by a VPWS A-D route or a LDP-LM message from the same PE, 339 then the EVPN-VPWS PE will setup the EVPN-VPWS PW. It may keep 340 the Legacy VPWS PW operationally down and MUST forward traffic 341 using the label information from that EVPN Ethernet-AD per EVI 342 route. 344 o For VPWS PE not using VPWS A-D or LDP signalling, the EVPN-VPWS 345 PEs need to be provisioned manually with PWs to those remote VPWS 346 PEs for each pseudowire. In that case, if an EVPN-VPWS PE 347 receives an EVPN Ethernet-AD per EVI route from a PE to which a PW 348 exists, it may keep VPWS PW operationally down and MUST forward 349 traffic using the label information from that EVPN Ethernet-AD per 350 EVI route. 352 6.1. Multi-homed Operations 354 Figure 3 below demonstrates multi-homing scenarios. CE1 is connected 355 to PE1 and PE2 where PE1 is the designated forwarder while PE2 is the 356 non designated forwarder. 358 EVPN-VPWS & MPLS/IP 359 Legacy VPWS Core Legacy VPWS 360 +---------+ 361 DF +---+ | | +---+ +---+ 362 +--|PE1|----|---------|---|PE3|---|CE2| 363 +---+/ +---+ | PW1 /| +---+ +---+ 364 |CE1| | / | 365 +---+\ +---+ | / | 366 +--|PE2|----|-----+ | 367 NDF +---+ | | 368 +---------+ 370 EVPN-VPWS Port-Active Redundancy 372 Figure 3 374 6.1.1. Operations with Port-Active MH PEs 376 In Figure 3, PE1 and PE2 are configured in port-active load-balancing 377 mode. Both PEs are advertising EVPN Ethernet-AD per ES route with 378 the single-active bit set as described in EVPN port-active document 379 [evpn_pa]. In this example PE1 is DF elected for the shared Ethernet 380 Segment identifier. 382 o Only PE1, as DF, advertises the VPWS A-D route or LDP-LM message 383 towards remote PE3. 385 o PE1 advertises the EVPN Ethernet-AD per EVI route for PW1 towards 386 remote PE3. The P-bit in L2 Attributes Extended Community is set 387 for PE1 as per [RFC8214]. The purpose is to have all required 388 EVPN-VPWS routes on remote PE so during an upgrade from Legacy 389 VPWS to EVPN-VPWS, those remote nodes are immediately upgraded. 391 o PE2, as NDF, only advertises its EVPN Ethernet AD per EVI route 392 corresponding to that same PW1. The B-bit in L2 Attributes 393 Extended Community is set for PE2 as per [RFC8214] 395 Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN 396 Ethernet Segment DF Election procedures described in [RFC8214] for 397 EVPN-VPWS. Furthermore, PE1 withdraws its VPWS A-D route or sends 398 LDP-LW message to remote PE3 to teardown the Legacy PW. Finally, PE2 399 advertises corresponding VPWS A-D route or LDP-LM message for that 400 PW1 and re-establish Legacy PW with new PE2 destination. 402 If PE3 is running 2-way pseudowire redundancy and PW-status is 403 enabled, PE2 may leverage the existence of standby/backup PW with 404 PE3. In this particular scenario, PE2 may advertise VPWS A-D route 405 or LDP-LM message along with PW-status message. 407 Once PE3 is upgraded and supports EVPN-VPWS, seamless integration 408 procedures are applied. Higher precedence of EVPN-VPWS over VPWS 409 allow all PEs to avoid the usage of legacy circuit. At that point in 410 time, non-preferred legacy VPWS protocols and configuration may be 411 removed from all PEs. 413 6.1.2. Operation with Single-Active MH PEs 415 Single-active operation is similar to Port-active load-balancing mode 416 described above but at the VLAN level instead being of at the port/ 417 interface level. 419 The main difference resides on the support of Legacy PW VC-type 4 vs 420 PW VC-Type 5 mode on the EVPN-VPWS PE as per [RFC4448]. While 421 services running in port-active load-balancing mode require raw mode, 422 services running single-active load-balancing mode use tagged mode. 424 6.1.3. Operation with All-Active MH PEs 426 In EVPN-VPWS all-active load-balancing mode, all PEs participating in 427 a redundancy group forward traffic bidirectionally, reducing the 428 importance of DF and NDF PE. However PEs running Legacy VPWS do NOT 429 support all-active peering PEs as remote endpoint. 431 6.1.3.1. Falling back to port-active 433 EVPN-VPWS PE discovering remote PE running VPWS PW MAY fallback into 434 port-active load-balancing mode. In that case, following rules are 435 applied: 437 o Peering PEs advertise EVPN Ethernet-AD per ES route with the 438 single-active bit set. They also advertise EVPN Ethernet-AD per 439 EVI route towards PE3 with P/B bit set accordingly as per 440 [RFC8214]. 442 o DF PE advertises VPWS AD routes or LDP-LM message and EVPN 443 Ethernet AD per EVI route per PW. 445 o NDF PE advertises only EVPN Ethernet AD per EVI route per PW. 447 o If PE3 is running 2-ways pseudowire redundancy, PE2 may leverage 448 the existence of standby/backup PW with PE3. PE2 may advertise 449 VPWS AD route or LDP-LM message with proper PW-status message. 451 6.1.3.2. Asymmetric forwarding 453 One privilege option is the asymmetric forwarding while peering PEs 454 run in all-active load-balancing mode. In the example of Figure 3, 455 traffic from CE1 going to PE1 is forwarded to PE3 using the VPN label 456 learned from VPWS AD route or LDP-LM message received from PE3. 457 Traffic from CE1 going to PE2 should get forwarded to PE3 using that 458 same VPN label. Traffic coming from CE3 to PE3 gets forwarded only 459 over the primary PW towards PE1; the DF PE. 461 Supporting asymmetric forwarding with purely LDP as per [RFC8077] 462 requires extensions to EVPN-VPWS MH procedures. These procedures are 463 NOT restricted only to LDP and may be applied to VPWS A-D. 465 Following rules are applied to achieve expected behaviour: 467 o Peering PEs advertise EVPN Ethernet-AD per ES route with the 468 single-active bit unset. That is to get the network ready when 469 remote legacy PE are upgraded to EVPN-VPWS. 471 o DF PE advertises VPWS AD routes or LDP-LM message and EVPN 472 Ethernet AD per EVI route per PW. 474 o NDF PE advertises only EVPN Ethernet AD per EVI route per PW. 476 o If PE3 is running 2-ways pseudowire redundancy, PE2 may leverage 477 the existence of standby/backup PW with PE3. PE2 may advertise 478 VPWS AD route or LDP-LM message with proper PW-status message. 480 o The tunnel encapsulation attribute [tun_encap] is used to 481 synchronize alias PW label between peering PEs. The tunnel 482 encapsulation attribute, specifying the alias PW label and tunnel 483 endpoint (nexthop) of the remote PE (PE3), is transmitted along 484 with EVPN Ethernet-AD per EVI route. The NDF PEs uses the same 485 VPN label per Legacy PW as DF PE when transmitting traffic coming 486 from CE (CE1) towards remote PE(PE3). 488 7. IANA Considerations 490 This document has no actions for IANA. 492 8. Security Considerations 494 The same Security Considerations described in [RFC8214] are valid for 495 this document. 497 9. Acknowledgements 499 The authors would like to acknowledge Sylvain Masse for his feedback 500 and contribution to this document. 502 10. References 504 10.1. Normative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, 508 DOI 10.17487/RFC2119, March 1997, 509 . 511 [RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, 512 "Provisioning, Auto-Discovery, and Signaling in Layer 2 513 Virtual Private Networks (L2VPNs)", RFC 6074, 514 DOI 10.17487/RFC6074, January 2011, 515 . 517 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 518 Virtual Private Networks Using BGP for Auto-Discovery and 519 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 520 . 522 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 523 Maintenance Using the Label Distribution Protocol (LDP)", 524 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 525 . 527 [RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J., and J. 528 Rabadan, "Virtual Private Wire Service Support in Ethernet 529 VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017, 530 . 532 10.2. Informative References 534 [evpn_fxc] 535 Sajassi, A. and P. Brissette, "draft-ietf-bess-evpn-vpws- 536 fxc", 2019. 538 [evpn_pa] Brissette, P. and A. Sajassi, "draft-brissette-bess-evpn- 539 mh-pa", 2019. 541 [RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, 542 "Encapsulation Methods for Transport of Ethernet over MPLS 543 Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006, 544 . 546 [RFC4664] Andersson, L., Ed. and E. Rosen, Ed., "Framework for Layer 547 2 Virtual Private Networks (L2VPNs)", RFC 4664, 548 DOI 10.17487/RFC4664, September 2006, 549 . 551 [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, 552 R., Patel, K., and J. Guichard, "Constrained Route 553 Distribution for Border Gateway Protocol/MultiProtocol 554 Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual 555 Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, 556 November 2006, . 558 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 559 LAN Service (VPLS) Using BGP for Auto-Discovery and 560 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 561 . 563 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 564 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 565 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 566 . 568 [tun_encap] 569 Patel, K., Van de Velde, G., and S. Sangli, "draft-ietf- 570 idr-tunnel-encaps", 2019. 572 [vpls_AA] Sajassi, A., Salam, S., Brissette, P., and L. Jalil, 573 "draft-sajassi-bess-evpn-vpls-all-active", 2017. 575 Authors' Addresses 577 Patrice Brissette (editor) 578 Cisco Systems 579 Ottawa, ON 580 Canada 582 Email: pbrisset@cisco.com 584 Ali Sajassi 585 Cisco Systems 586 USA 588 Email: sajassi@cisco.com 590 Luc Andre Burdet 591 Cisco Systems 592 Ottawa, ON 593 Canada 595 Email: lburdet@cisco.com 597 James Uttaro 598 ATT 599 USA 601 Email: uttaro@att.com 603 Daniel Voyer 604 Bell Canada 605 Montreal, QC 606 Canada 608 Email: daniel.voyer@bell.ca 610 Iman Ghamari 611 Telus 612 Canada 614 Email: Iman.Ghamari@telus.com 615 Edward Leyton 616 Verizon Wireless 617 USA 619 Email: edward.leyton@verizonwireless.com