 Good afternoon everyone. Very excited to be back at the Open Networking Summit this time to talk about enabling digital transformation through open software-defined infrastructure. In the short time that we have today, I will first spend a few minutes to talk about who we are and what we do at Visa. I will then share some thoughts about our technology transformation vision as well as our approach to building an open software-defined infrastructure including some of the guiding principles and drivers behind their vision. I will then spend a few minutes to outline an open architectural framework for a data center network architecture based on software-defined networking and we'll also talk about some use cases for SD-WAN or software-defined networking for the wide area networks. Time permitting. I will then spend some time on the migration aspects of SDN and also what we as a community can do to help accelerate the industry adoption of software-defined technologies. Who is Visa? Visa is a global payments technology company. We connect consumers, businesses, financial institutions, strategic partners and government entities in over 200 countries to fast, reliable and secure electronic payments. Our advanced transaction processing network facilitates the authorization, clearing and settlement of digital payments and also enables us to offer a wide range of product and value-added services to our customers. Visa operates in a four-party model, as can be seen on this slide, including merchants, the card issuing banks and the acquiring banks. As such, we are not a bank. We don't issue cards. We don't set credits or credit limits or rates or fees for the account holders of Visa products. As one of the world's largest retail electronic payments networks, our infrastructure today serves over 16,000 financial institutions and enables over 129 billion payment transactions a year for a total volume of 8.2 trillion US dollars at some 65,000 transaction messages per second. While these numbers speak to the already significant scale of our infrastructure, we foresee a continued growth of electronic payments driven by new technologies, new innovations, as well as a shift of consumer habits. These drivers include an accelerated growth of e-commerce and a rapid migration of e-commerce to mobile devices. But also, there is a number of underlying, enabling technologies that are creating new payment models, such as blockchain or tokenization, which is a technology that allows you to replace the card number with a digital token to make the transaction more secure. This technology, for example, can be in the Internet of Things ecosystem, where every connected device can now become a potential point of sale. These new technologies and trends will continue to emerge and evolve as we move toward the cashless society, and these technologies and drivers will continue to set new requirements on the infrastructure in terms of growth, resiliency, security, scale, performance and unit cost. Such new drivers and requirements are at the heart of our technology transformation work at Visa. A great focus of our transformation journey is really around leveraging software to create an increasingly open digital platform for innovation, but also increasing the agility of the infrastructure and adding layers of security and operational resilience. It is also about making electronic payments accessible to everyone worldwide. Today, about half of the population on Earth does not have access to electronic payments. And as we grow and expand our infrastructure, we need to make sure that we can continue to offer the same and greater levels of resilience, security and agility to billions of connected devices and users. A big part of our thinking is around moving away from closed and proprietary physical infrastructure devices to open and software-based technologies, to be able to build that agility in software and offer on-demand infrastructure and network services to our customers. In 2015, we launched Visa's developer platform, which now offers over 180 of Visa's product and service functions through APIs to our customers and partners. Some of the examples of architectural principles that we are embracing as part of this technology transformation journey includes leveraging software to build resilience independently of hardware. We know that hardware can fail, circuits can fail, port or an interface can go down, but we need to make sure that we can build resilience, availability and security in software independently of hardware. So that no single failure or even multiple failures of network or infrastructure devices would result in any service impact. And separation of hardware and software is a big portion of that. And as we grow and expand our infrastructure, we need to make sure that we can continue to maintain real-time full visibility across the entire data path in our infrastructure. And once again, that can only be achieved in software at scale. We're also looking at opportunities to maximize the asset utilization, not just from a PCO advantage perspective, but also from the standpoint of improving the efficiency of our operations and actually making the infrastructure more resilient and more highly available. These ideas include things like consolidating separate physical networks into one common fabric, both on the WAN side as well as the data center side, but also simplifying and reducing the number of stack layers that we have in the networking stack. Let's now talk about a framework for an open, software-defined data center network architecture. In this example, more suitable for an enterprise environment, everything starts with building a physical network fabric that you want to keep as simple as possible, leveraging the leaf spine topology design for improved scale and resilience as well as the support of microservices, but also leveraging simplified slash commoditized hardware with merchant silicon chips and a minimal set of standard networking features. Next, you want to make sure that you keep your architecture modular and your abstraction layers well-defined, including the network switching and virtualization, then a software layer for network orchestration, monitoring, control, and management, and then your application layer, where you can have different types of workloads, including bare metal or non-virtualized workloads that can interface directly with your hardware, such as Hadoop or Spark, or you can have virtualized workloads such as VMs and containers for which you might want to leverage some sort of a network virtualization technology, and then as your virtualization footprint grows, you might want to leverage and deploy a dedicated SDN controller platform to manage that state centrally and at scale. And it is extremely important that the interface between that consolidated, unified SDN controller with the rest of your physical infrastructure be open and standard-based, so that you can select the best-of-debrate technologies for each of these components. You might also want to leverage some virtualized network functions for layer-for-layer seven functionality, such as load balancers, firewalls, et cetera, and manage that whole physical infrastructure from within that SDN controller. Now in a real-world enterprise data center environment, you have other networking functionalities that need to be provided. These can include a packet capture fabric for which you can similarly leverage simplified and commoditized hardware with some SDN capabilities, as well as an out-of-band network management fabric that can interface with the rest of your physical fabric. Now once you have built all of that, you want to make sure that you can actually leverage and harness the true power of software through an orchestration platform, where as the previous speaker mentioned, with the point and the click, you can actually provision your infrastructure and build whatever network service that you want without having any knowledge of the hardware. And equally importantly, it is important that that interface be open similarly to the SDN controller interface. Now let's shift gears and talk about WAN. So outside the data center, typically an enterprise has some sort of a WAN network or wide area network. Starting from the left side of the slide, an enterprise might have a number of remote sites. These includes branches or customer premises or a number of users that just connect to your environment through internet and or through some sort of a carrier-managed connectivity. And then you have your data centers, either one or several of them, typically connected through an enterprise-managed data center interconnect or backbone network. And then you might have some presence in a public cloud. So here the blue boxes represent the areas where the enterprise has some visibility and control and the rest is really kind of third-party managed. So while this model works for many enterprises and in many use cases, it comes with some challenges. You typically have some sort of a legacy router or technology on the access site. And for the vast majority of the transport network, you don't really have much visibility and control. And if you have thousands of these devices and if you're running a mission critical environment, that whole process of managing the life cycle of these devices, which can come in thousands, can be pretty significant. Now, software-defined networking can help address some of these challenges and there are several scenarios and deployment models. I will talk about three use cases. There are more. In this use case, a carrier can offer an SD-WAN solution at the edge of the network where networking functionality is moved from these end devices to the edge of the network and then in a virtualized environment, you have some sort of a VCP environment where you can actually manage your networking capabilities and create some interesting service-changing functions and manage a large number of your end devices from that point of presence or edge of the network. And then you have a similar setup at the terminating site where the traffic is handed over to your data centers. So this model does offer great advantages in terms of simplifying the operations of your WAN infrastructure, but also it might come with some challenges. Typically, if you require carrier redundancy at the access, you want to make sure that the carrier that offers this service can actually offer carrier redundancy and an environment where you can leverage access connectivity from multiple providers, but also leverage internet or even wireless. But also in the WAN side, you want to make sure that the SD-WAN solution that the carrier offers is unbundled from the carrier transport offering so that you can actually work with multiple carriers for the transport of your network if needed. A second use case is when the enterprise kind of replaces the legacy equipment and the access site and actually works with an SD-WAN vendor. So here I put two vendors, the kind of light blue vendor and the green vendor. This model can also work very well because now you have a global state of your end points and your access sites that can be managed centrally from within software from your data center. With this model, similarly to the previous model, you can actually create a lot more interesting traffic engineering and policy-based routing decisions and actually manage the state of your end points centrally and from within software. So a few important considerations with this model is that if you're a large enterprise and you have many end points deployed around the world, you might want to decide that you want to have different vendors or two or three vendors and partition your network. And it is important that you don't have to deploy a new set of controller platforms and management platforms every time you bring a new vendor. So as such, it is important that the southbound for these devices also be open and multi-vendor compatible. And that is the yellow line that I put on top of the SD-WAN router devices. Next scenario is when the enterprise actually expands their backbone network as far as possible and as close as possible to the end users. This way effectively managing the large portion of the end-to-end path themselves instead of relying on third-party carriers. So in this scenario, the enterprise not only owns and manages the data center interconnect network but also the WAN backbone. And now the enterprise has the opportunity to deploy these SD-WAN solutions at the pop or at the edge of the network and only rely on third-party carriers and other methods of access for the WAN access portion. So here with this model, you can actually have a number of pops around the edge of your network geographically spread and then from there on manage your end points that can connect to your network either through internet or through wireless or through a number of carrier-provided MPLS circuits. So each of these scenarios has pros and cons and advantages or disadvantages depending on how much visibility you want to gain, how much control you want to have on your infrastructure end-to-end and also the CAPEX and OPEX resources involved is different for each case. So the ability of which model you want to go for, it is important to understand that in order to make the adoption of these solutions easier, these solutions need to be open and come with standard interfaces. It is equally important that these solutions can be easily and seamlessly integrated with the enterprise's operational environment. But also it is important that the engineers in an enterprise organization can actually test these capabilities and also test the interoperability between different multiple vendor solutions in software. So it is important that vendors offer a virtualized environment for these platforms so that you can have the kind of network CI CD environment to test and evaluate these solutions. It is also important that these solutions be flexible. So no vendor lock-in, hardware independence is also equally important and as I mentioned it is important that the carrier transport be independent from the carrier SD-WAN solution. Needless to say that these SD-WAN solutions need to maintain or even improve the carrier greatness of the typical networking solutions that we are used to but also provide the global support and come with the right level of security hardening. I will now say a few words about the migration aspects of SDN. A few years ago in the Open Networking Foundation within the migration working group, a number of documents were published to describe the use cases, the methodologies as well as the tools that should be considered during an SDN transformation journey and this slide kind of highlights some of the thought process from that work. So we published the blog by that name by the way. So the thought process is pretty straightforward. You have a starting infrastructure. You go through a phase migration phase step and then you have your target SDN-based infrastructure. You want to make sure that your starting network is well understood and that the state is well understood and that you have well defined back out procedures. So if during the migration something goes unexpectedly you have the right mechanism in place to roll it back and then during the phase migration you want to make sure that you have continuous availability and also the right tools in terms of monitoring, provisioning and troubleshooting. And then once all that migration work is done, how do you make sure that you actually have the SLAs that you had previously and that in this new environment you have the right paybooks from an operational perspective. And these are not just on paper theoretical work. These are things that actually we have been doing at Visa as part of our migration process toward these new technologies. So a brief summary of some of the thoughts that I mentioned in terms of coming together as a community to help accelerate the adoption of SDN and software defined technologies. There has been a great momentum to move away from hardware centric solutions to software defined technologies and as of recently there have been announcements for even established vendors to make their OS available to run on third party hardware. This is a great example of a very good step in the right direction. So let's come together to do more of that kind of shift from hardware centric to software defined offerings. It is important that all these SDN solutions, whether it's on the data center side or on the WAN side, remain vendor neutral and offer multi-vendor deployment opportunities to enterprises and customers. Do not put that work on the shoulder of the enterprise so that the engineers that are trying to build and deploy these solutions actually have to do all that hard integration work. Also, we need to make sure that these solutions can easily and smoothly be integrated in the enterprises operational environment. In most enterprises there is a lot of focus on availability and operational effectiveness and many enterprises try to leverage the best of the breed tools to detect anomalies and outages and failures as quickly as possible. So every time a new solution is deployed, we need to make sure that these solutions can be easily integrated in existing operational platforms and once again open APIs is the right answer to that. Similarly to the example that I mentioned with our Visa developer platform, let's make sure that whatever capability we are building in the community, we make it accessible and available through APIs to the community so that we can build greater synergies and opportunities for more SDN deployments. And finally, let's make sure that the SDN solutions can coexist with legacy environments. There is a lot of deployments today in enterprise but also across the industry on green field deployments but in many cases these SDN solutions need to be deployed in environments where there will be a mix of legacy with green field technologies. With that, thank you very much for your time. I'm now happy to take questions from the audience. Justin? Hello. Hi. Amazing change. You went from Huawei, a CTO type, were you building products and developing next generation products and working with customers but now you are a customer? It seems like a huge change and a lot more responsibility when you have all those transactions and all those billions and billions running through the network every day. Well, you look thinner. How do you compare the two jobs? I think this one's more challenging but can you say something about that? Your journey? Absolutely. So, this talk is really about what we have been doing at Visa. I'm happy to answer that. So last time I was here I remember I talked about accelerating the pace of innovation by leveraging SDN and there were a lot of great ideas and proof of concept types of ideas. And at Visa we have really been putting those ideas and concepts to practice. And some of the ideas that I mentioned are actually part of our network transformation journey and a lot of the story that I mentioned here is already well underway in terms of what we do to really take a very large-scale mission critical environment through this journey and leverage software and software-defined networking and show that it can work both on the WAN side as well as the data center side. And as I mentioned, some aspects that I believe have not been talked about enough in the industry over the last few years is how do you make sure that you can easily operationalize SDN? A lot of things look nice on paper but when you try to put this into a mission critical environment and try to drive that change in flight, it is a different story. So there is a lot more work that we need to do as a community to lower the barrier to entry for large enterprises and organizations that are actually managing a mission critical environment. Thank you for the great question. Happy to see you again. Please. Post-migration, how much of the big vendor like around Tasman Drive, the big C, how much of that was left or how much of a part is it playing in your infrastructure now? I'm sorry, I'm not sure I understood the question. Without naming the vendor right, the vendor around Tasman Drive, the big C, how much of that is left in your infrastructure post-migration? If I understood the question correctly, I'm not sure I can speak to the details of how much infrastructure from a particular vendor is left in our organization but I can tell you that we are working with all vendors, including the established ones who all are going through this transformation journey and we are trying when we have the opportunity to leverage the best of the breed technology components for each part of the network. As I mentioned in one of the slides, we are seizing the opportunity to go from close proprietary technologies to more open and software-based solutions and I think across the board, all vendors, both the established ones as well as the startups, are actually embracing that movement. Thank you. Next question. Thank you for sharing your journey into establishing this SDN into your infrastructure. Could you tell us how much of your infrastructure has been migrated to SDN and how much of it is left on, as you described it, legacy hardware? Are you 100% now SDN driven? Are you using SDN 100% in terms of your infrastructure or are you 50% there, 10% there? Could you give us an idea? It is hard to quantify but across the board, as I mentioned, it's a journey. It is a full spectrum where we have opportunities to deploy green field deployments. We are definitely seizing the opportunity to leverage SDN but our infrastructure is large and it is a journey that we are going through so the short answer is I cannot really tell you the exact quantified number in terms of the percentage of the infrastructure that has been already migrated to SDN but that effort is well underway and it is making good progress. Please, next question. I was really interested by your different network architecture diagrams. It took me a while to realize that you are describing sort of the infrastructure of visa that you are migrating from legacy to SDN. My question for you is which one of those transitions do you find to be the most challenging or do you think is the most important for you to make and also which ones still need more development from the industry to enable you to be successful in that transition? Great. Thank you very much. Great question. I am getting a cue that we are running out of time. I will answer briefly and be happy to discuss offline. From my perspective I think on the one side the transition and the transformation will probably be longer because that is a little bit newer technology and it is less established than on the data center side so that will be my short answer and I will be happy to discuss that offline with you. Thank you very much, Al. I think we are running out of time. Do we have time for one more question? One last question. Sure. The last question is do you see any differences of the trading position to serve the commercial banks or credit clearance? The open source software versus the commercial software has a lot of things to be improved or qualified to be insight into the visa network. Do you see any differences between how do you qualify the process I mean how do you qualify the open source versus the qualified commercial software? Yes, I will provide a short answer and we'll be happy to discuss offline. I personally believe that open source today can actually provide a great level of robustness in terms of the quality of the code, as well as good as a commercial piece of hardware because there is the whole community involved. And within Visa, we have a very well-defined process to operationalize new technologies including open source. So in my opinion, both types of code can work equally well in a mission critical environment whether it's open source based or kind of the commercial grade code if I understood correctly your question. Thank you. Sure. Thank you very much. All right. Thanks Justin. Thank you very much. Thank you.