 Good morning. You've heard Dr. Yal and Margaret talk about two different perspectives, how to work with open source and what kind of commercial things you can do with open source. But I actually want you to point, I want to point to a slightly different perspective. You actually witnessed two biggest networking vendors come into open source. So that's, I think, who says networking is not transforming, right? What I'm going to walk you through is Verizon's perspective on open source, why we like open source, why we want to work with it. But before going there, I'll kind of give you a little bit of context on where we stand and what is driving some of this. If you look at our traffic patterns across wireless global IP networks, they're going up. I mean, this is a story that you will hear from any carrier. They're going up at 40%, 50% a year, year over year. And this does not account for what is evicting, right? Things like AR, VR, AI and all. When those things start becoming mainstream, we expect these to actually accelerate the growth. At the same time, when you look at the industry, industry is evolving. VR seeing competition come from different areas. Even on the networking side, now you're hearing a lot about high-altitude platforms, whether it is SpaceX or not somebody else. Are you looking at the web-scale carriers deploying massive amount of fiber across the globe? So there is different kinds of competition emerging. Number of networks that each carrier is managing is increasing. Not only that we still have 1X, 2G, EVDO, and others, but we are deploying 5G, and we are working on, even on the fioside, multiple flavors. So as the variability of the network increases, there is a bit of complexity. And finally, the transformation complexity. This entire forum is about SDN and FE. And carriers haven't reached a point where this becomes a BAU thing. We are still exploring, figuring out what is the right way between us and the vendors and the open source bodies and others. There's a lot of work to be done to make this seamless. Same time, when we look ahead, there are new pressures that are going to come across at us. The physical, traditional integration, Sandra talked about and others talked about. When you live in a world of augmented reality and autonomous vehicles, networks can't just be managed by just varying bandwidth. That's what we've been doing. We were selling minutes of usage, and then we went to gigabits and megabits of bandwidth. We have to start looking at other levers to deliver those experiences. Latency is definitely one of them. Mass around connectivity. So networks will have to be developed to start providing those sort of experiences in slices. And that increases the amount of complexity within the network systems. The other point I want to point out is if you look at traffic between wire line and wireless, 80% of the IP traffic that goes on the carrier networks, and I'm going to talk a bit about US here, comes from five publishers. It might differ, for example, on wire line. We'll see Netflix being one of the biggest driver of traffic. If you go into the wireless, it's YouTube. But effectively, 80% of the traffic is going to five publishers. What does this mean? What this means is we're no longer a north-south traffic management company or organizations. We are also dealing with a lot of east-west traffic management because we have peering partnerships with these companies. Most of the traffic is finding the quickest way to exit our networks and enter these publishers' networks. So it's a different paradigm, a different way of building networks than the way we were building networks in the past. The third point that we look at is that we've built networks to have this monolithic centralized control. But the use cases that are going to emerge down the road will require networks to be ad hoc, dynamic. You may want to create networks to the edge and terminate them at an instant's notice. You'll require a very different kind of control system to manage this dispersed ecosystem. And that is, again, driving networks to look at what sort of future paradigms we could adapt to. And finally, there was a lot of talk about distributed clouds. This is what is going to be the future of networks. It's virtualized. And we are able to run any application anywhere in the network, all the way to the light pole having a computing storage, running any kind of packet code application or any application, you call it, to the centralized data warehouses, data centers. And networks are software-driven. They are adopting what IT teams have gone through, DevOps and Cloud and whatever else. But this also kind of illustrates the point I was making before is that it's about moving the traffic east-west. We're going to operate similar to the way what WebScale and other companies have figured out and do it in a very optimal sense. Networks will have to kind of get there. So why open source? Promise of scale and resiliency. And so when we look at the pioneers in this area who have developed white-box solutions and who figured out how to move traffic between data centers, we start seeing that the networks are going to be in this manner. We are going to have a large number of data centers. We'll have to start moving traffic. We see how the open-source principles were implemented by some of these WebScale providers. We see the same things can apply, and we can leverage some of those learning. The second key point is telco carriers typically followed standards. But standards bodies tend to be slow. It takes time. So what is happening now is that being part of the open-source communities, we're able to get like-minded people together, talk about things that make sense, quickly put that into code, and then take a deployment. The timescale difference between what you can do through a standards body versus what you can do through an open-source community is hugely different. And so this becomes extremely, extremely attractive. The other key point is we see that in open communities are companies that have implemented open-source-based solutions. Automation and others almost come in both internally because there is a natural development by the developers and others. But there's a lot of community contribution towards solving the problems. That is, again, attractive. And today when we deploy networks, appliance-based networks, and rely on one or two vendors, a problem to a solution typically has to come from that one or two vendors. And it takes time. Any kind of automation, any kind of optimization others, we're still relying on those vendors. In this paradigm, I think we see the community behind us and the community can actually help innovate faster. And finally, dollars. I mean, there's definitely in open-source the cost structures are different than what we're used to. So it's an interesting thing. So why are we not jumping in at full speed? This slide kind of reflects internal dilemmas that we go through. There are multiple groups. In fact, we are going through these conversations now about OSM, Onap, who's behind it. Remember, we talked about that these are becoming pseudo standards groups. So if you can get more people into one group, then you can actually influence the ecosystem and drive. Change is faster. But which ecosystem? So we're going through all these conversations. What we need is we need to see more deployments. We also need to see more contribution from a wide variety of sources. We've had examples where companies come and say, I've got this tool, or I've got the software, and it's open-source. And look who's developing. There's like one company developing. There's no contributors in that. We're seeing a lot of that confusion. And we've got to work beyond that. Finally, there's also, desegregation as a topic has been talked quite a bit in the last one and a half, two days. Open-source is driven by desegregation where each one of us can innovate in specific areas. But what's driving is that we need to do a lot more integration than what we had done in the past. What they ask for vendors in our suppliers is what we see today is at the lowest level is open-stack packaged around some of the proprietary functionality and given to us. And when I try to integrate that with somebody else's functionality, it gets extremely complicated. What we want to ask for vendor community is you can innovate on your own applications and others. But make sure that the integration becomes open. You follow the standard, or you follow the communities and open models and others so that we can integrate much faster across vendors, across different open-source projects and others. And that needs to be the one that needs to be solved. Finally, our ask is, harmonize the groups. There are a lot of open-source groups doing a lot of different things. I don't think we're recommending that it needs to be one open-source group or a project. But I think we need to have more dialogue between the teams, especially if we're all abstracting things quite a bit, then there has to be some level of integration level conversations that need to happen. We need to move towards deployable solution. At the lower levels, we are seeing open-stack and others. Carriers are deploying into the field. And we can see scale. We can see massive volumes of data going through them. But as we slowly start moving upwards, we haven't seen deployed solutions. Any questions? I know I have a minute.