BESS Working Group P. Brissette, Ed.
Internet-Draft A. Sajassi
Intended status: Standards Track L. Burdet
Expires: May 20, 2020 Cisco Systems
J. Uttaro
D. Voyer
Bell Canada
I. Ghamari
E. Leyton
Verizon Wireless
November 17, 2019

EVPN-VPWS Seamless Integration with Legacy VPWS


This document specifies mechanisms for backward compatibility of Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) solutions with legacy Virtual Private Wire Service (VPWS). It provides mechanisms for seamless integration in the same MPLS/IP network on a per-pseudowire or per flexible-crossconnect service basis. Implementation of this document enables service providers to introduce EVPN-VPWS PEs in their brown-field deployments of legacy VPWS networks. This document specifies control-plane and forwarding behaviour needed for auto-discovery of a pseudowire in order to enable seamless integration between EVPN-VPWS and VPWS PEs.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on May 20, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

Virtual Private Wire Service (VPWS) is a widely-deployed Layer-2 VPN (L2VPN) technology. Many service providers, who are looking at adopting Ethernet VPN Virtual Private Wire Service (EVPN-VPWS), want to preserve their investment in the VPWS networks. Hence, they require mechanisms by which EVPN-VPWS can be introduced into their brown-field legacy VPWS networks without requiring any upgrades (software or hardware) to these networks. This document specifies control-plane and forwarding behaviour needed for auto-discovery of a pseudowire in order to enable seamless integration between EVPN-VPWS Provider Edge(PE) devices and PEs running legacy VPWS services in the same MPLS/IP network.

                  MPLS/IP Core              
      +---+    |               |   +---+
      |PE1|----|----- PW1 -----|---|PE2| Legacy VPWS
      |   |----|---+           |   +---+
      +---+    |   |           |   
   EVPN-VPWS & |   +--PW2---+  |   +---+  
   Legacy VPWS |            +--|---|PE3| EVPN-VPWS
    (hybrid)   |               |   +---+

Seamless Integration of EVPN-VPWS.

Figure 1

Figure 1 shows a simple network where PE1 runs in hybrid mode (EVPN-VPWS and legacy VPWS). It provides a pseudowire (PW1) with PE2 running legacy VPWS. It also provides a pseudowire (PW2) with PE3 running EVPN-VPWS. PE2 may be upgraded to EVPN-VPWS seamlessly. Legacy PEs may be setting up PWs per [RFC8077] or may be setting up a VPWS service by first auto-discovering VPN members using [RFC6074] and then setting up the PWs using [RFC8077] or [RFC6624].

The seamless integration solution described in this document has the following attributes:

- It is backward compatible with [RFC8214] and EVPN Flexible crossconnect Service [evpn_fxc] document.

- New PEs can leverage the multi-homing mechanisms and provisioning simplifications of EVPN Ethernet-Segment:

  1. Auto-sensing of MHN / MHD
  2. Auto-discovery of redundancy group
  3. Auto-election of Designated Forwarder and VLAN carving
  4. Support of various load-balancing mode such as port-active, single-active and all-active

One of the objective of this document is to describe how a legacy VPWS brown-field network can be migrated seamless to EVPN-VPWS. Usually, it is achieved in few steps. For example, let say PE1 and PE2 from Figure 1 have a legacy PW established between them. First, network operator may upgrade PE1 to support EVPN-VPWS. Once upgraded, PE1 which now have the EVPN-VPWS capability still runs legacy VPWS PW with PE2. Later on, network operator may decide to upgrade PE2 to support EVPN-VPWS. As soon as the upgrade is completed, EVPN-VPWS service takes high-precedence over legacy VPWS network. The network operator can safely remove any legacy configuration related to that PW from PE1 and PE2 nodes. PW remains established as an EVPN-VPWS service.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Terms and Abbreviations

3. Solution Requirements

Following are the key requirements for backward compatibility between EVPN-VPWS and VPWS:

These requirements collectively allow for the seamless insertion of the EVPN-VPWS technology into brown-field VPWS deployments.

4. Seamless Integration

In order to support seamless integration with Legacy PEs, this document may require Legacy PEs to setup PWs per [RFC8077] or may require Legacy PEs to setup VPWS service by auto-discovering VPN members using [RFC6074] and then setting up the PWs using [RFC8077] or [RFC6624]. Furthermore, EVPN-VPWS PEs must support BGP EVPN routes per [RFC8214] and one of method of legacy VPWS technologies. All the logic for seamless integration SHALL reside on the EVPN-VPWS PEs.

5. Capability Discovery

The EVPN-VPWS PEs MUST advertise both BGP VPWS Auto-Discovery (VPWS A-D) route or LDP-LM message as well as the BGP EVPN Ethernet-AD per EVI route for a given pseudowire.

In the case of VPWS PEs running VPWS A-D, they may advertise the BGP VPWS A-D route, per the procedures specified in [RFC4664] and [RFC6074]. The operator may decide to use the same BGP Route Target (RT) to identify a pseudowire on both EVPN-VPWS and VPWS networks. In this case, when a VPWS PE receives the EVPN Ethernet-AD per EVI route, it MUST ignore it on the basis that it belongs to an unknown SAFI. However, the operator may choose to use two RTs - one to identify the pseudowire on VPWS network and another for EVPN-VPWS network and employ RT-constrained [RFC4684] in order to prevent BGP EVPN routes from reaching the VPWS PEs.

When an EVPN-VPWS PE receives both a VPWS A-D route or a LDP-LM message as well as an EVPN-VPWS Ethernet-AD per EVI route from a given remote PE for the same pseudowire, it MUST give preference to the EVPN-VPWS route for the purpose of discovery. This ensures that, at the end of the route exchange, all EVPN-VPWS capable PEs discover other EVPN-VPWS capable PEs. Furthermore, all the VPWS-only PEs discover the EVPN-VPWS PEs as if they are standard VPWS PEs. In other words, when the discovery phase is completed, the EVPN-VPWS PEs have discovered the remote PE per pseudowire along with their associated capability (EVPN-VPWS or VPWS-only), whereas the VPWS PE have discovered the remote PE per pseudowire as if it is VPWS-only PEs.

6. Forwarding and Control Plane Operations

Figure 2 demonstrates a typical brown-field deployment where PE2 is a legacy PE and PE1 is an EVPN-VPWS PE.

       EVPN-VPWS &      MPLS/IP   
       Legacy VPWS       Core        Legacy VPWS
          +---+    |               |   +---+
          |PE1|----|----- PW1 -----|---|PE2| 
          +---+    |               |   +---+
   VPWS A-D route  ]  TX       TX  [ VPWS A-D route
        or         ] --->     <--- [      or
 LDP Label Mapping ]               [ LDP Label Mapping
  EVPN per EVI/EAD ] --->

EVPN-VPWS Single-Homed

Figure 2

The forwarding state setup procedures on the VPWS PE are per [RFC8077], [RFC4761] and [RFC4762].

The EVPN-VPWS PE procedures are as follow:

6.1. Multi-homed Operations

Figure 3 below demonstrates multi-homing scenarios. CE1 is connected to PE1 and PE2 where PE1 is the designated forwarder while PE2 is the non designated forwarder.

       EVPN-VPWS &   MPLS/IP   
       Legacy VPWS    Core       Legacy VPWS
      DF  +---+    |         |   +---+   +---+
 +---+/   +---+    |   PW1  /|   +---+   +---+
 |CE1|             |       / |   
 +---+\   +---+    |      /  |
       +--|PE2|----|-----+   | 
     NDF  +---+    |         |

EVPN-VPWS Port-Active Redundancy

Figure 3

6.1.1. Operations with Port-Active MH PEs

In Figure 3, PE1 and PE2 are configured in port-active load-balancing mode. Both PEs are advertising EVPN Ethernet-AD per ES route with the single-active bit set as described in EVPN port-active document [evpn_pa]. In this example PE1 is DF elected for the shared Ethernet Segment identifier.

Upon link failure between CE1 and PE1, PE1 and PE2 follows EVPN Ethernet Segment DF Election procedures described in [RFC8214] for EVPN-VPWS. Furthermore, PE1 withdraws its VPWS A-D route or sends LDP-LW message to remote PE3 to teardown the Legacy PW. Finally, PE2 advertises corresponding VPWS A-D route or LDP-LM message for that PW1 and re-establish Legacy PW with new PE2 destination.

If PE3 is running 2-way pseudowire redundancy and PW-status is enabled, PE2 may leverage the existence of standby/backup PW with PE3. In this particular scenario, PE2 may advertise VPWS A-D route or LDP-LM message along with PW-status message.

Once PE3 is upgraded and supports EVPN-VPWS, seamless integration procedures are applied. Higher precedence of EVPN-VPWS over VPWS allow all PEs to avoid the usage of legacy circuit. At that point in time, non-preferred legacy VPWS protocols and configuration may be removed from all PEs.

6.1.2. Operation with Single-Active MH PEs

Single-active operation is similar to Port-active load-balancing mode described above but at the VLAN level instead being of at the port/interface level.

The main difference resides on the support of Legacy PW VC-type 4 vs PW VC-Type 5 mode on the EVPN-VPWS PE as per [RFC4448]. While services running in port-active load-balancing mode require raw mode, services running single-active load-balancing mode use tagged mode.

6.1.3. Operation with All-Active MH PEs

In EVPN-VPWS all-active load-balancing mode, all PEs participating in a redundancy group forward traffic bidirectionally, reducing the importance of DF and NDF PE. However PEs running Legacy VPWS do NOT support all-active peering PEs as remote endpoint. Falling back to port-active

EVPN-VPWS PE discovering remote PE running VPWS PW MAY fallback into port-active load-balancing mode. In that case, following rules are applied: Asymmetric forwarding

One privilege option is the asymmetric forwarding while peering PEs run in all-active load-balancing mode. In the example of Figure 3, traffic from CE1 going to PE1 is forwarded to PE3 using the VPN label learned from VPWS AD route or LDP-LM message received from PE3. Traffic from CE1 going to PE2 should get forwarded to PE3 using that same VPN label. Traffic coming from CE3 to PE3 gets forwarded only over the primary PW towards PE1; the DF PE.

Supporting asymmetric forwarding with purely LDP as per [RFC8077] requires extensions to EVPN-VPWS MH procedures. These procedures are NOT restricted only to LDP and may be applied to VPWS A-D.

Following rules are applied to achieve expected behaviour:

7. IANA Considerations

This document has no actions for IANA.

8. Security Considerations

The same Security Considerations described in [RFC8214] are valid for this document.

9. Acknowledgements

The authors would like to acknowledge Sylvain Masse for his feedback and contribution to this document.

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC6074] Rosen, E., Davie, B., Radoaca, V. and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, DOI 10.17487/RFC6074, January 2011.
[RFC6624] Kompella, K., Kothari, B. and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012.
[RFC8077] Martini, L. and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J. and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017.

10.2. Informative References

[evpn_fxc] Sajassi, A. and P. Brissette, "draft-ietf-bess-evpn-vpws-fxc", 2019.
[evpn_pa] Brissette, P. and A. Sajassi, "draft-brissette-bess-evpn-mh-pa", 2019.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N. and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006.
[RFC4664] Andersson, L. and E. Rosen, "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, DOI 10.17487/RFC4664, September 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K. and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006.
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007.
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007.
[tun_encap] Patel, K., Van de Velde, G. and S. Sangli, "draft-ietf-idr-tunnel-encaps", 2019.
[vpls_AA] Sajassi, A., Salam, S., Brissette, P. and L. Jalil, "draft-sajassi-bess-evpn-vpls-all-active", 2017.

Authors' Addresses

Patrice Brissette (editor) Cisco Systems Ottawa, ON Canada EMail:
Ali Sajassi Cisco Systems USA EMail:
Luc Andre Burdet Cisco Systems Ottawa, ON Canada EMail:
James Uttaro ATT USA EMail:
Daniel Voyer Bell Canada Montreal, QC Canada EMail:
Iman Ghamari Telus Canada EMail:
Edward Leyton Verizon Wireless USA EMail: