This blog is a collaboration with co-author Lukas Krattiger, Distinguished Technical Marketing Engineer

---

Innovation is one of many characteristics defining industry leadership. Becoming an industry leader requires a company to innovate and find new ways to solve customer problems. Industry leadership is not something that can be created overnight. It takes more than a software release or a list of supported features to cement yourself as a technology thought leader in the networking industry. Over the past several decades, Cisco has demonstrated its leadership in networking by leading technology innovations that meet and exceed customers' needs and then enabling the adoption of these technologies across organizations driving standardization. This has also led to robust collaborations and interoperability among different vendors for the benefit of the industry as a whole -please refer to Figure 1 Number of RFCs authors per affiliation for the top 30 companies at IETF over the past three decades.

Some examples of such technologies are L3VPN, MPLS, and EVPN. Cisco technology pioneers such as Eric Rosen, Yakov Rekhter, and George Swallow incubated MPLS and L3VPN technologies and then led the standardization effort at the IETF. Furthermore, Cisco innovator and technology pioneer, Ali Sajassi incubated EVPN technology and then led the standardization effort at the IETF. A well-adopted standard is like a team sport, and it requires not only participation but also contributions from every member of the team -i.e., from every vendor and provider involved.

Figure 1. Number of RFC authors per affiliation for the top 30 companies at IETF over the past three decades

In the past decade, Cisco has introduced EVPN technology to the networking industry at large and has led the standardization efforts for all the initial RFCs for this technology with the help of several vendors and service providers. Although there are vendors who are true partners and contributors to this technology and its standardization, there are "others" who are neither participants nor contributors but just users of it. One can easily find out who is who by looking at the IETF statistics for EVPN.

These "other" vendors have made claims to be pioneers of cloud networking fabrics driving a standards-based approach, even though they are openly adopting and implementing Cisco-authored RFCs and drafts into their software. These "other" vendors attempt to create the perception of open standards as their core pillar. Cisco has been a long-time innovator with a proven track record of developing IETF drafts to facilitate the implementation of new technologies that are widely adopted by these other vendors ("others") in the networking industry. Being an industry leader requires Cisco to continue evolving and driving standards to make networks work better -please refer to Figure 2. Chart showing the number of EVPN RFC Primary Authorship, EVPN RFC Authorship, and Working-Group Authorship Affiliation:

Figure 2. Number of EVPN RFC Primary Authorship, EVPN RFC Authorship, and Working-Group Authorship Affiliation

IETF

For most of us, it is widely known the IETF is the premier Internet standards organization. Citing the IETF Standards page:

"Improving existing standards and creating, implementing, and deploying new standards is an ongoing effort. The IETF's mission is to produce high-quality, relevant technical documents that describe these voluntary standards. IETF working groups are the primary mechanism for the development of IETF specifications and guidelines."

As EVPN-VXLAN becomes the de facto standard for IP fabrics, Cisco continues to enhance and publish IETF drafts based on the protocols and architectures addressing new requirements and use cases. When Cisco develops the standards and drafts, there is an implementation in mind for the system and its parts, while "others" will choose to follow and implement the RFCs and the drafts without a full understanding of the use cases.

These other vendors will create and leverage feature matrices to fill their gaps and respond to RFPs, citing our documents and acting as if they would know better. Cisco can confidently claim to lead while "others" only follow, while Cisco invents and "others" only adopt.

Figure 3. VXLAN EVPN Industry Contribution

Cisco continues to extend its leadership in promoting open standards, interoperability, and multi-vendor solutions for Cloud Networking technologies.

This series of blogs aimed to provide a deeper understanding of EVPN VXLAN and additions to the IETF drafts implemented for today's customer deployments.

History of Ethernet VPN (EVPN)

For many years, the need for extending Layer-2 efficiently was a burdensome task. Before the availability of Layer-2 VPNs, sorts of LANE (LAN Emulation) were used to transport Ethernet across distances, or we just plugged two Ethernet domains together via CWDM or DWDM. All these approaches had their pros and cons, but some common challenges remained, the virtualization of the Layer-2 service across a common infrastructure. When MPLS-based Layer-2 VPN rose to prominence, the presence of true Layer-2 VPNs became available, and with this the better use of the underlying transport infrastructure. With VPLS (Virtual Private LAN Service) multipoint-to-multipoint Layer-2 VPNs became affordable and addressed many new use cases. Even though VPLS brought many advantages, the pseudo-wire maintenance, transport dependency, and lack of comprehensive embedded access node redundancy still made it challenging to deploy. While all of this was the truth over a decade ago, around 2012 we embarked on a new chapter of Layer-2 VPNs with the advent of Ethernet VPN in short EVPN. In its essence, EVPN addressed the challenges the more traditional L2VPNs incurred and innovated new schemes in layer-2 address learning to become one of the most successful VPN technologies.

The journey of EVPN as a standard started back in 2010 when Ali Sajassi introduced and presented the very first draft of EVPN (initially called Routed VPLS, draft-sajassi-l2vpn-rvpls-bgp-00.txt, to IETF (Internet Engineering Task Force) in March of 2010. This draft was later merged with another draft by Rahul Aggarwal (from Juniper), draft-raggarwa-mac-vpn-00.txt, because of their synergy, and a new draft was born in October 2010 - draft-raggarwa-sajassi-l2vpn-evpn-00.txt. This draft became a working group document in February 2012 and became a standard RFC 7432 in February 2015. This is the defacto base RFC for the basic EVPN behavior and its modes and subsequent EVPN RFC builds on top of the groundwork of this RFC.

Around the same time as the main EVPN draft introduction, Cisco introduced other EVPN related drafts such as draft-sajassi-raggarwa-l2vpn-evpn-req-00.txt and draft-sajassi-l2vpn-pbb-evpn-00.txt in October 2010 and March 2011 respectively which became standard in February 2014 and September 2015 respectively.

After the publications of initial EVPN drafts that later became RFCs 7432, 7209, and 7623, in 2013, Cisco published another set of EVPN drafts for Virtualization/VxLAN and for inter-subnet forwarding (L2 and L3 forwarding) that gave EVPN its versatility as it stands today. These drafts later became the standard RFCs 8365 and 9135.

Figure 4. IETF EVPN Timeline

With the based EVPN using MPLS encapsulation celebrated its success in the Service Provider market, for the Data Center an IP-based encapsulation was more suitable. With this, in 2013 the EVPN draft for "overlays" (draft-sd-l2vpn-evpn-overlay) was published, which included the encapsulation of VXLAN and became RFC 8365 in 2018. In order to address the various use cases for the Data Center, a couple of related drafts were filed around the same time. The definition of how to do inter-subnet routing (draft-sajassi-l2vpn-evpn-inter-subnet-forwarding), how we advertise a IP Prefix route in EVPN (draft-rabadan-l2vpn-evpn-prefix-advertisement) or how to interconnect multiple EVPN "overlay" domains with a Data Center Interconnect (draft-rabadan-l2vpn-dci-evpn-overlay). All these drafts from 2013 now being RFCs and define the standard in how EVPN is being used within and between Data Centers.

Figure 5. EVPN RFC for VXLAN and DCI

The realms of standards are often a cabala. Opening this up and sharing some of the histories with the most significant milestones is as important as defining the standards themselves. For more than a decade, Cisco has actively driven the standardization of EVPN and shared this innovation with the networking industry. With over 50 publications to the IETF, Cisco leads the EVPN standardization and is proud of the collaboration with its partnering authors. With the proliferation of EVPN across all of Cisco's Operating Systems (IOS-XE, IOS-XR, NX-OS) being fully interoperable, the flexibility of the right operational model across deployments in Campus, WAN, Data Center, or Service Provider domains is unmatched.

Summary

Ethernet VPN or EVPN has a long history in the industry, celebrating 10 years of shipping and deployment in various Cisco network operating systems (NOS) surpassing the lifetime of many networking companies.

There is a sense of pride to see how an idea flourishes and becomes a mainstream network technology with a wide customer and networking vendor adoption. While there is always the option to keep all to yourself, we believe in the community and providing standards for better networking.

Learn more about Cisco data center and cloud networking technologies