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.
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:
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.
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.
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.
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
authoring RFC is an outstanding job but executing RFC in software is another “thing”
Appreciate the time for sharing your thoughts on RFCs and how they help to improve products. Cisco has been one of the three vendors to ship EVPN for nearly a decade. We started back in 2013 with PBB EVPN and continued with EVPN on NX-OS (Cisco Nexus 5600, Nexus 7000, and Nexus 9000) and IOS-XR (ASR 9000) in 2015. Starting around 2018, we started shipping EVPN on IOS-XE (ASR 1000 and subsequent Catalyst 9000).
For your reference, please see the following publications:
PBB EVPN on IOS-XR in 2013
https://blogs.cisco.com/sp/e-vpn-and-pbb-evpn-take-data-center-interconnect-to-the-next-level
EVPN on IOS-XR and NX-OS in 2015
https://investor.cisco.com/news/news-details/2015/Cisco-Continues-Open-Standard-Leadership-With-Support-for-EVPN-VXLAN-Overlay-Protocol-on-Nexus-9000-Series-Switches/default.aspx
EVPN on IOS-XE in 2018 https://www.cisco.com/c/en/us/td/docs/routers/asr1000/release/notes/xe-16/asr1000-rel-notes-xe-16-3.html
it wasn’t a request about on which software but more on how and what quality (which means how it works)
Cisco ever implemented EVPN? Most of customers are used to things like ACI, LISP, EIGRP. Question to authors: what exactly do you mean by saying “and implement the RFCs and the drafts without a full understanding of the use cases”? It is only Cisco who understand the use case of those RFCs?
Thanks for your questions and yes, Cisco has shipped EVPN for nearly a decade. We started in 2013 with PBB EVPN and continued with EVPN on NX-OS (Cisco Nexus 5600, Nexus 7000, and Nexus 9000) and IOS-XR (ASR 9000) in 2015. Starting around 2018, we started shipping EVPN on IOS-XE (ASR 1000 and subsequent Catalyst 9000). Please refer to the links in the previous response for more details on the very specifics.
Cisco being customer-centric, we do not just focus on individual technology building blocks, even as we do provide them as a choice. Cisco uses such technology building blocks for end-to-end SDN (Software Defined Networking) solutions to our customers, such as SDA (Software Defined Access) (using LISP) as our Campus Fabric or ACI (using VXLAN plus additional enhancements) for the Data Center Fabric.
The authors of the participating vendors on EVPN have established a collaboration over the years hashing out many details. With the many intricacies and dependencies amongst the EVPN RFCs, the authors themselves tend to have a more comprehensive understanding of the full body of vs. a non-participant.
Are you claiming you “lead” because you write standards after you implemented some proprietary solution beforehand? That is a bit shortsighted. I wonder how good ACI is selling compared to EVPN setups of “other” vendors. Because that is what I always saw Cisco pushing for, their blackbox ACI stuff.
Nowadays Cisco is known for being the old-school enterprise vendor for people who really don’t want the new stuff or have too much money lying around for closed solutions. Writing blog articles like this is not going to change that. This article seems typical of Ciscos snotty, stuck-up attitude that we experienced when were still customer. Maybe we did not have enough millions of spare cash lying around to throw at you, but we were really not impressed with you trying to sell us something without listening what our needs were.
Maybe you’re leading in paying people to write RFCs, you’re surely not a leader in understanding your customers or actually implementing RFCs. Change that and maybe we will reevaluate you again in a few years. Or stick with old-school enterprise customers, they like to do stuff like they did 10 years ago.
Interesting point of view and of course we appreciate you taking the time to read through the blog. When it comes to Data Center Switching, ACI and EVPN are individually presented as Data Center networking options for our customers since 2015. While some of our customers are interested in a D-I-Y (do-it-yourself) approach and want to implement the bits and pieces, other customers are more appealed to a turnkey SDN solution. As a side note, ACI and EVPN are not mutually exclusive as ACI leverages control-plane functionality provided by EVPN.
Writing RFCs is a contribution and collaboration between vendors and operators; in our case these are customers. By looking at the list of RFC authors, you can see very wide participation across the board. As part of this wide collaboration, customers had a big hand in shaping RFCs, specifically but not exclusively when it comes to EVPN. This said I want to highlight that baseline RFC for EVPN started as a solution to address a specific customer’s problem.
Great travel into the Time Machine.. brought back some great memories! Thanks Richard, Lukas!
EVPN becoming a mainstream capability esp. in the DC is really cool. Many would have thought that it would be limited to backbone metro Ethernet use cases. However, the shift in workload communication patterns made it a viable choice for customers inside DC to carry L2, L3 reachability info simultaneously over BGP.
Thanks to all the folks who made it a reality. ?? Onwards and upwards!