 Okay, good morning. I'm going to talk to you today about operators and about open source, and about open source orchestrator as opposed to closed source orchestrator. And I'm going to make a comparison. For those of you who are not expert in onboarding new services, I'm going to have a one-minute explanation of what does it really entail. When you want to have a new service, you need to onboard it. You take the VN as an operator, you consume the VNF from the VNF vendor, including all of the artifacts, TOSCA, automation script, all the code that comes with it from the VNF vendor. Then, once you approve it and certify it, you have it on the drawing board and you start putting up the service on the canvas. You add the automation script for the service, the policies, the workflow, and it's ready to be tested. Now you test it, usually those bugs, this issue, going back to the drawing board in an iterative manner until it's being ready, and then you package it and you move it to operation. After you distribute it, it's in operation and it's either going to work for some time, but if there's issues, you need to rebug it. This picture is very beautiful on one hand, but it derives a very, very complex and labor intensive process. What you see in the following slide, you don't need to understand every square, every tile here, but you need to understand that every tile here actually means labor, cost, OPEX, sweat and tears, months or a period of time in a cascade manner, in a waterfall manner, until the service is ready. In fact, every box here represents the embodiment of what's... I mean, we moved to NFV because we wanted to have a lower OPEX ability and those sets of boxes and that's just engineering and operation, this is actually working against the business case of NFV because it's a very, very long process. So I'm going to give you an example of troubleshooting an NFV issue and that's something that we had in live cases with our customers and I'm going to show you how we run this in two environments, one of them with an open source orchestrator or at least orchestrator that the community has access to and the other one with closed source orchestrator and you would see, I think by the comparison of one box, that which one is really easier. Let's say you have an NFV issue. We have three pillars here. At the center we have the CSP, the operator. At the right side we have the closed source proprietary orchestrator company organization and the left side we have the VNF vendor organization. What's happening is the following. You have a problem, it is error, it is discovered in operation. Clearly somebody make a phone call to engineering inside the operator still. We need to troubleshoot something. Engineering and operation sit together and understand what is the problem and they are calling 1-800-VNF vendor and they say there's a problem. Let's sit with tech support and try to understand what happened. Tech support starts to troubleshoot the problem and then they say we need to talk to product manager because it's a real problem. It requires some modification. Now the problem usually are some of the TOSCAP code is not really ready. Something is not working in the way that the VNF is orchestratable. Product management says wait, maybe actually wait a second. Maybe the TOSCAP script that we delivered without VNF are good. Maybe it's the orchestrator that is not orchestrating the good TOSCAP script that we have provided. So now you're adding the VNF, the orchestrator vendor, the closed source orchestrator vendor to the loop. Now you really have to triangulate because what you're actually doing, you're looking at several black boxes. The orchestrator which is the black box, there's the VNF which is the black box and you have to look at the behavior of this in a several time zone in a huge team to understand where the problem is. And then it goes to R&D and it goes to testing and usually in this point you can no longer do it with phone calls, you need to have face-to-face. So in the cases that I was involved in, it always end up with all the engineer going to some exotic place to have some sort of off-site and resolve it. Now, with the exception that people have in fun, what you see on this slide, this spaghetti, is the anti-material of OPEX reduction and agility. This is something that is impacting the value of NIV. And that's just one box out of the 15 boxes I show you. Okay, this is one component. Let's look at the safe thing in an open source environment. CSP in development finds that there is an error, right? Okay, it goes to engineering. Engineering says it's really an error, we are aligned. Let's go to the VNF vendor. They go to the VNF vendor. VNF vendor says, look, you know what? There's an open source... We are part of one app. There's an open source orchestrator. The problem is the orchestrator. It's not our artifact, it's the orchestrator. The CSP answer is the following. If there is a problem with the orchestrator, fix it. You have the capability to contribute to it. In fact, the VNF vendor has the entire orchestrator in his lab with the code of the orchestrator in his lab. It can run everything in his lab, right? So, and he's empowered to be a contributor or maybe even a committer to the open source distro. And so there's no offside in exotic place, but if you look at the amount of errors in the two options, you see that it's a substantial difference. Now, I think the takeaway I have for you today, and again, there's two things. First thing, if you download the presentation from today, there's 15 boxes of steps in the operator, like onboarding the new VNF, certifying it in our environment. Each one of them has the same left and right picture. Each one of them has the ramification for the operator on a massively deployed open source and the ramification for the operator which is using closed open source. But for me, I think when people... It's like, you know, you ask the people in the street, what is 5G for you? It's like 5 grand. When you ask people in the street, what does open source orchestrator for you means? They would say it's free. I guess the license is very cheap. I can have a fast, you know, I can switch vendor very fast, which supports very fast because I can have several flavors of the same thing. And all of that is true. But in my opinion, the fact that you're no longer using black boxes and the fact that you're on the left side of the slide, where you can actually interact and demand that each one of your supporter, including the VNF vendor, is in command. And if there is an error, there's no pointing fingers. I think it's a huge benefit and it shows you how agile this is. So with this, we still have time for a very short question. Question? Okay, thank you. I had a question. So after the VNF vendor fixes the problem in the open source orchestrator, what is the time that it takes to go through the open source acceptance process and make it back into the production version that the service board actually uses in their network? Great question. Firstly, it depends on what organization it is. There is a committer. The committer is... Thankfully, you can always do it just to test it. Since you have access to the code, you can always do the change incrementally without committing to the upstream. So you can just fix it for now, okay? So the short answer is you can do it immediately. If you want it to be part of the big distro of the open source, then it depends on the organization. Actually, in ONUP, there's a cadence of several... Every period is going to be a new version. I don't know what it is. But as I said, to solve the problem on a fork, small fork, until the new change is accepted, immediate. As long as the problem is discovered. Okay? Okay, thank you very much.