Cisco Logo


Architect & DE Discussions

A team of us at Cisco has been working, together with industry colleagues, on defining and standardizing a new Layer 2 VPN solution known as Ethernet Virtual Private Network or E-VPN. In this post, I will discuss the key requirements that helped shape this solution, and attempt to shed some light on the drivers for the technology and how it enables the evolution of Service Provider L2VPN offerings.

The ubiquity of Ethernet has fueled growth in the deployment of provider provisioned L2VPN services over the past decade or so. This coincided with multiple strides in the technology to address the issues of redundancy, scalability, multicast optimization, inter-AS support and OAM for both VPLS as well as VPWS. While these solutions were gaining maturity and wide adoption as enablers for E-LAN and E-Line services, the requirements for Layer 2 VPNs kept evolving. This evolution catapulted over the course of the last 2 to 3 years, primarily as a result of service providers and enterprises foraying into new flavors of L2VPN services such as E-Tree, Virtual Private Cloud and Data Center Interconnect.

If you have tinkered with software or networks (or any engineering system for that matter) over a long enough lapse of time, then you know from first-hand experience that only a finite set of optimizations can be performed on a system before a paradigm shift is required, in order to address the next wave of requirements.  For the purpose of our discussion, this paradigm shift is embodied in the departure from the data-plane learning modus operandi of VPLS to the control-plane learning model in E-VPN.  Several requirements associated with the new L2VPN services, mentioned above, serve as the drivers for the technology’s evolutionary shift.

One of these requirements is to provide support for enhanced redundancy with fine-grained (i.e. per flow) load balancing across provider edge nodes in a multi-homed setup. This is of particular relevance in data center interconnect and cloud services, where it is critical to increase the aggregate bisectional bandwidth between the customer network and the provider’s edge for all VLANs that are being extended over the MPLS network. With the existing data-plane MAC learning model, it is not possible to support this requirement because a given MAC address can only be associated with a single pseudowire, and consequently with a single provider edge node. As a result, in the best case, VPLS can support per-VPN load balancing among provider edge nodes.

A second requirement is to provide support for flexible VPN topologies and elaborate forwarding policies. This requirement is driven by E-Tree and Cloud services alike, where it may be desirable to restrict connectivity among different categories of sites within a given VPN (e.g. Root vs. Leaf sites) or to specify forwarding behavior on a per MAC address basis (e.g. for Lawful Intercept). The data-plane learning model does not lend itself towards supporting these capabilities easily because, by its very definition, data-plane learning is distributed, autonomous and transparent. This is where the choice of BGP as the control-plane for E-VPN brings in a rich set of policy customization and control capabilities.

A third requirement is to provide support for optimal delivery of multicast using multipoint-to-multipoint (MP2MP) LSPs. This requirement is applicable to any L2VPN service where the scalability demands of the deployment call for reducing the amount of control and forwarding state that has to be maintained, on the label switching routers, for the optimal delivery of multi-destination traffic. MP2MP LSPs do not have any inherent mechanism to identify the sender over the shared tree. Consequently, data-plane learning simply cannot be performed over MP2MP LSPs.

The E-VPN solution is being designed to address all of the above requirements and more by performing MAC distribution and learning, over the MPLS network, in the control plane using multiprotocol BGP. While E-VPN introduces a paradigm shift from existing VPLS and VPWS solutions, it does bring L2VPN technologies closer to L3VPN in terms of the general operational model and underlying protocol machinery. As such, it can be characterized as an evolution of MPLS-based L2VPN solutions to enable a richer set of capabilities and introduce a new set of services. How do you see E-VPN adding value to your network?

In an effort to keep conversations fresh, Cisco Blogs closes comments after 90 days. Please visit the Cisco Blogs hub page for the latest content.

3 Comments.


  1. Hi Samer,

    What are your thoughts on using E-VPN to create a Layer-3 Data Center Fabric? Juniper is already using this technology (perhaps with some proprietary enhancements) in QFabric. Do you see Cisco introducing E-VPN (with that BGP and MPLS support) in some of the TOR switches based on IOS and NX-OS?

    I am keen to find out because a lot of vendors are focusing on L3 fabric.

    Best regards,
    Amit.

       0 likes

    • Thanks Amit, these are great questions!

      E-VPN can provide an integrated routing and bridging (IRB) solution that offers not only Layer 2 but also Layer 3 connectivity between edge nodes. The E-VPN MAC Advertisement route has an IP address field that can be used to propagate Layer 3 addresses. Furthermore, E-VPN can seamlessly interoperate with IP-VPNs as discussed in this draft.

      The industry’s focus is sharpening on Layer 3 fabrics, as you said, and this can be seen in the Data Center requirements and framework that are actively discussed in the IETF NVO3 workgroup. It is worth pointing out that the E-VPN control-plane can be used with IP-based encapsulations such as VXLAN, as discussed here. Technology-wise, introducing E-VPN in the ToR switches is a viable option. However, Cisco isn’t ready to make any public statements at this time on which additional technologies might get adopted over time for Layer 3 fabrics.

         0 likes

  2. Blake (First Name)

    “How do you see E-VPN adding value to your network?”

    By finally ending the decades-long nightmare of multivendor spanning-tree interop in redundant PE-CE L2 interconnects, or various other nonstandard solutions that have unsuccessfully tried to replace it in the past.

    This is what 802.1D should have been in the first place.

       0 likes

  1. Return to Countries/Regions
  2. Return to Home
  1. All Architect & DE Discussions
  2. Return to Home