 Thank you, Jeremy, for the panel you have set. Hello, everyone. Let's start. Thanks for coming this evening for a special seminar. Christos called us. Most of you know him. He's been involved with SDN since the very beginning. He's a senior research scientist at ORANZ. And today he's going to be talking about how to bundle NFV with SDN and an open call for researchers to work on this topic. All right. Thank you. Thank you so much, Jeremy. I'd like to thank Nick and his group also for supporting these. Thanks for all of your attention. Today is such a late time of the day. So I'll be talking about the bundle NFV and SDN. So like in the open networking framework, as you see, I used all of the different passwords that I just made. I can use that more than that. But hopefully it's a point where it makes it interesting. And so this is like work in progress, meaning that there's like some thoughts that I have and also the group behind NFV also has. And also if you don't agree with something, feel free to speak up. And if you need to ask a question or if it's something that is not really clear, you can stop me. Otherwise, different questions to the very end. So that's in terms of context. NFV is about the abstraction of network function from dedicated hardware. And I'll get to that later on. And the kind of technician that, of most of us at least, agrees the SDN's abstraction to control flame from the data plane. So the concept behind NFV is that if you look on the thing on your left, you see the legacy network deployment that we have today in our networks, whether it's a network or it's a telco network or an apparatus network. We have all these different hardware that is dedicated to specific network function. We have load balancers, you know, five volts and feedback inspection devices and so forth. And you have one physical node per row, right? So we have one particular box that does one thing. And also it requires physical installing. So you have to send someone out in the field to install back. It's very static, so which means it's very hard to move. It also makes very inefficient in terms of if you need to handle spikes in a traffic. And also it's inefficient because most of them actually they're sized for peaks, right? And if you only, it's like 10% digitalized obviously that device is under-utilized. So as a result, this is very hard to scale up and out. So the vision behind NFV is that we should try to move everything into software. Okay, anything that is today in terms of network elements and runs on hardware, which is moved back into software running on commoditized servers, essentially. And that gives rise to the virtual network appliance. So now in order to achieve the same performance, obviously you have to use a high volume number of servers, right? Because it's not like one of only one server was gonna match the performance of one particular box. And I was thinking about servers, that doesn't necessarily mean, and I want to clear that because it's misconception out there that we're talking about x86 type of architecture. So that's not true, it can be any architecture, right? Some people obviously know that they're using x86 platforms and obviously that's what they advertise. But if you look at the white paper that we did in October of 2012, we never said that it has to run on x86. Actually as far as I'm concerned it can run these functions on their metal servers. But they don't even have to use virtualization, right? But the thing that we, in order to reach the economies of scale, but they have to run on VMs. So that's the vision of behind an RV. And everything you see here, you know, we get the contrast, the exact mirror description of the appliances. Now that's upper base, you can have multiple rows running on the same part because the hardware not right now is your server. It can be remotely operated and that's a big plus for us as an operator. If we want to dispatch someone out in the field, we can run things remotely, you know, easy to scale and so forth. Okay, so, this is like summarized of the different types of applications we see in a V-fitting, essentially any transic entity in the network operators. Environment can be moved into software running on servers, from mobile networks to home environment, including your home router, hopefully. Any CDN, security is very, very big and traffic monitoring and so forth. Anything, again, that runs on dedicated hardware today, the vision behind an RV needs to move into software. This is one slide because I'm thankful for asking this question. So, just to give you the framework, we operate under Etsy. Etsy is the European Telecommunication Standards Institute. It's based in Europe, but this is a global effort. We have 28 plus carriers assigned on this effort and we have more than 200 members out. I've been lucky enough actually to be involved in this group from the get-go, essentially. So, it is related. We operate as a standards body. The only thing is that we don't produce standards. So, the goal here, the objective here for the Etsy and RV is to produce the specific cases. We have a lifespan of two years and actually we're gonna expire net now, January of 2015. So, we have four working groups that try to cover most of the areas that we think are of interest, from the infrastructure to the software architecture to the management orchestration, which is a very important area as we talk later on. We have also the liability and availability and also have a couple of experts groups on security and performance and portability. So, the main output is just like guidelines? Yes, the main output, right. The main output actually is guidelines and in fact, we published the first set of documents of November, October last year. It covers the use cases, the architectural reference framework, terminology, and also it's important as the proof of conscience. So, essentially, you can see how this can happen in absence of standards, you know, but I mean, it's like an effort at this point, right, to see what it leads us. The idea is that once this group expires next year, maybe we'll see whether it's gonna transform itself into a standards body or, you know, or maybe we're gonna split all the different pieces and then, you know, different organizations actually can pick up the piece and move on. So again, you know, we don't produce, yes. Can you describe the scope of proof concepts? Like, are they in the lab setting? Are they pseudocode? Are they actually working in the field? Right, so they had to be, well, it varies. So we've seen proof of conscience like in a lab environment, essentially, or it could be some pilot project out in the field. The objective of that is the sense of like, you know, showcase, you know, what can you do with NIV and also to, you know, expose any issues. So you can feed that back into the working groups. The way that Pocs abstract is that you have to have one operator last to vendors minimum, right? So obviously, you know, this is the showcase how the operators can use NIV to, you know, essentially implement these in the networks. Is there someone who says that, okay, this proof of concept meets the guidelines? Right, so the process actually is quite loose at this point. So it's not like there's a formal body that says, you know, yes or no. So essentially, Etsy and I think that the chair of the ability group essentially said if it conforms the guidelines that were published, you know, it's a go ahead. So we have so far, I think we leave 14 or 15 Pocs. Some of them, you know, are really important. We want, you know, marginal, but yeah, there's not like an industry in the process that says, you know, you can be part of it or not. That's what you're asking. So it's pretty loose at this point. Okay, so we have to ask more of these questions. I think I don't have much stuff, you know, on the Pocs and the Etsy structure because this Pocs is about SDN and NIV in the open and working environment, but I'll be happy to, you know, share slides with the one if you have questions. Okay, so why NIV? So we think that NIV presents a number of benefits. I sort of summarized this in what they call the EVA, principle of the sense of velocity and agility. That's a flexibility to rapidly dynamically, essentially, providing instantiate those functions because now these are running on VMs so you can launch them, you know, whenever you think that there's a need for that. It's an increased speed time to mark. This is very important for us as network operators. If we want to launch a new service in the past or actually currently it takes too long because we don't have to work with the hardware vendors. We think that once you move things into the server, it gives you more flexibility and speed and also personal efficiency because now everything is running on VMs that presents a more homogeneous type of environment versus in an environment we have to deal with many, many vendors at the same time. We think that this can lead also to reduced equipment costs, but you have to keep in mind here that instead of buying a hardware, dedicated hardware, I have to buy those servers, right? So we need to sort of like do the analysis here. We need to deal with this kind of exercise, the trying to find the right business case and say, you know, if I have one box here, it maps to that many VMs and actually do the actual cost. You know, how much this is going to cost. So no one's done that yet? So no one has done that yet. I mean, as far as I haven't seen it and it's not really a Monday. So that's why I focus less on the CAPEX and ALPEX benefits and people who say, oh yeah, we think that's going to lead to that at some point, but I can't tell you whether it's going to be 30% or it's going to be a mere 10% debt. So, but we're hoping that people, you know, we'll work on that and maybe vendors can come up and say, come up and say, you know, this is what you guys are saving and so forth. That's going to be very case dependent, I think, in my mind. But it's a very important exercise to do, right? Because that's really, that's what the sense of this thing is, lives. And, but we think that, you know, in terms of certain ALPEX, we're going to see some savings, whether it's the energy, you know, if I'm interested in paying for that, and especially in terms of skill set. Because now, when you start moving things into VMs, we think that the required skill set in terms of personnel, it's not going to be as demanding as today with the dedicated hardware. But again, this is something that remains to be seen. So in your experience, do carriers have these kind of people that work with software, work with VMs, less with hardware? Yeah, so what we will see happening, in a sense of this is, so today things are run mostly by the network, by the, by the knock-wits network operator center. And so when you move to this environment, where you have things running on servers, that's an IT department, that's right. So the answer to your question is yes, major vendors, major, sorry, major operators do have the resource to do that, but what we see actually is the convergence between the network infrastructure people and also the IT department. But again, I don't emphasize this right now because again, this remains to be seen. I want to emphasize on the fact that since now we're moving things into the software, that opens up a number of opportunities for us. And plus we know, we try to avoid and stay away from that vendor lock-in that we have today when it comes to dedicated hardware. Okay, so we have, as part of the, of these specifications that we're producing, we have a document on use cases and I think that like a number of use cases, there are I think seven or eight or 10, I can remember the exact number, but we've split up the use cases into architectural use cases. And so here, I mentioned a few of interest. One is the network function virtualization infrastructure as a service, which is essentially this diagram here. It's not, and I'll come back to that later on to explain that. The virtual network function is a service so where you actually can deploy a VNF, a VNF is a virtualized network function. So if you want to write a firewall, for instance, you know, you can go to a provider that provides that as a service and, you know, get that from them or it can be, you know, the virtualized CPE, something that you can also run remotely as a service. Then there's also the virtual network platform as a service, that's another use case. Essentially, in terms of scope, the VNF PIS is larger than this one. It allows also for multi-tenancy at the VNF level. And one of the last use case present here is the VNF forwarding graph. Now this is the same as the service chaining, which in case you've heard that term before, now I'm assuming that most of you haven't heard that before. Okay, so I'll come back to this example later on. I have a few slides to describe that. Okay, and so the other set of use cases that that includes are service-oriented use cases. So these are like more, bigger in terms of scope here. You can see different essentially entire architectures presented as use cases. You see the mobile core network, for instance, the base stations and CRAM, the home environment as, you know, the utility, CDNs, you know, it's another important use case for us, especially for us as veterans. We are submitting a talk on CDN. So the other interesting thing that, and I'll come back to the issue of a world packet called VPC is that only you can sensor to transform dedicated hardware into, you know, those single boxes. But you can take entire architectures and move these into software. And I'll talk at the end about the VPC test, but that we're building in our lab in San Francisco. So you see, and then I'll also showcase, you know, how SDN also fits into that. Okay, so this is the reference architecture model that we came up, again, this is work that was done last year. So you see a number of pieces here. The important thing to remember is that this is the infrastructure that the VNFs would be running on. So you see the bits of computing storage and network, and this is the actual hardware resources. That's the infrastructure, the network function visualized infrastructure. On top of that, you have the VNFs running and you see the OSS, the DSS system. That's the integral part of the network. And on the side here, you see the management orchestration. So the management orchestration is responsible for the lifetime management of those VNFs. Now those VNFs, again, run on VM systems, right? So someone has to launch those VMs. If you need to move a VM, somebody has to take care of that. If you need to tear down, bring down a VM, someone has to do that. So that's part of the management orchestration. That's the most critical part in NFP. So you have the visualized infrastructure manager here that manages the infrastructure. You have the managers here that manage the VNFs and also this is the orchestrator. So this, again, is a very, very key component in NFP. So in terms of examples here, and I'm gonna be focusing, most of my talk today is gonna be focusing on the service training, which I think presents most of interest when it comes to NFP and SDN. So it is an example of a service training where everything is virtualized so you don't have any physical boxes in your infrastructure. So it shows, you have what is different VNFs running and the different lines here represents the traffic flow. The package's coming into the system. You have to somehow dispatch and check in. This package goes to the load balancer and the load balancer has to go to the firewall and from the firewall to some other VNF, right? That constitutes the composition or chain of VNFs of the virtualized, visualized network functions. So different colors here represent different sensory service chains, if you like. And again, this is totally a virtualized environment. Now, VNFs may have a metadata associated with them because you may want to identify VNF, right? So that's an open research problem, actually. And the second example is when you go to environment which is most likely that's where we start with, where you have a hybrid infrastructure. You have physical boxes that exist today in the network and then also you have the virtualized part of it that it's gonna augment or enhance the physical infrastructure. Now, have you said that because the question of migration would come up or how do we migrate? That's not gonna be that hard because you can run these things in parallel so you can have your physical infrastructure that runs as it does today and also you can start building your virtualized infrastructure at the same time, right? So that's gonna be an easy, we can do that in parallel. The only issue here is that when it comes to traffic, someone has to decide, okay, this package needs to go to the physical infrastructure and this package needs to be visualized infrastructure. So I think that's probably one of the components when it comes to hybrid infrastructures. And so essentially, you know, this picture here, right? What was that? These are not that visible because I cannot see them myself. So but you have, you know, those physical box don't actually have those VNS running. And so the, another example here, which I think is of interest, which is kind of like new when you start thinking about the VNS is we can have nested VNFs. You can have a VNF within another VNF. So that opens up, you know, new areas of research as well. Okay, so here I have like a couple of slides on, these are my personal thoughts. So when we, you know, move to this new paradigm of where everything is visualized. I like to, you know, sort of like pose and ask a few questions. So question number one is whether we need to create a data plane, which is NMV at work. Or if we need to make our, you know, our data plane NMV at work. So with the physical hardware again, connection between the boxes are static. So nothing moves, right? That's pretty much it. When you go to these NMV environment, everything is dynamic and you can have VMs moving around. You know, going to, you know, other racks, other data centers across your infrastructure. So it's sort of a different dynamic environment. So keeping that in mind, then the forwarding plane needs to handle, you know, that forwarding and switching. You need to somehow keep track of how the flows in the network traverse across the different servers. And also when it comes to bandwidth requirements, you know, things are changing. Because again, in the current paradigm you have static connections, right? So the bandwidth on a specific connection is given. And it cannot be changed. But when you move things around, again, everything becomes more dynamic. So how do I make sure that I allocate the right capacity for instance to a service chain that means it has particular specific bandwidth requirements. And this has to be done, not just at the single node level, but I think most like at the network level as well. And also we think that multi-tenancy will have to play a big role when it comes to the data plane. So the next question obviously is, okay, do we need an NFP or a control plane, right? I haven't said that about the data plane. So when it comes to the control plane, now servers can host multiple VNFs, right? So not only one visualized micro-function. We have the network service composition. This is the service chain I talked about. You know, you have a number of firewalls or balancers, you know, interconnected. Do I need a control plane essentially to again keep track of these type of connections of the operating or service chains? And so also the control plane needs to maintain some traffic steering. What about quality of service and other policy rules that you may have? And also, as I said before, we're gonna see at least for some time a mixed environment would have visualized and unvisualized elements in your network. And the question I'll also ask you at the end is that do we actually need a controller for NFP? And as perhaps you have guessed, the third pillar here is whether we should make our applications and the VR world. And what does it mean, right? So first of all, we have to see what is the impact, it's gonna be the impact on current applications that are running today on a network and adapt the success application to this environment or perhaps design new applications that take into account the energy. Also, the application at least in my mind has to be very optimized oriented because now you have put resources, which is kind of different what you have in the past, in the past you have dedicated resources to all these different functions, but now you have put resources, so you have to make sure that you use those resources effectively and efficient. And the other thing I had here is that whether that's the role of the non-bound interface between the VNS and the application. So today you don't have applications that, at least maybe you have a few applications, we look at CDN, but most of the applications don't directly interact with the physical boxes today, to run on top of your system. But as we open up those VNS, maybe you can have applications that directly are in the interface, if you like, with the virtualized type of boxes. We also think that once you're going into this thing, that that opens up some monetization opportunities for us, particularly for service providers. Again, these are questions that I'm just throwing out, to see what people think and whether it doesn't mean that Etsy actually were doing that, that this is my only thoughts. Okay, so when we published the white paper back in October of 2012, we were actually quite visionary to include this Vend diagram from the very beginning. So we had the open innovation as one circuit here. Well, SDN, because SDN within is a certain part of this effort. And also this, the third cycle here was the end of it. As you see, these cycles intersect, okay? They don't overlap exactly, 100%, but they intersect. So obviously, we like to operate right there. But for now, we think that there's definitions between SDN and NFV. These are independent technologies, they're independent architectures if you like. They don't depend on each other, but they can benefit if they were together. That's, it's my also personal conviction and actually that's what people think also within the group. So that's the intersect there. And again, keep in mind that the common denominator here is software. So when you look at SDN, we have software and everything in NFV is actually software. So that simply finds things a lot when it comes to essentially leveraging SDN in NFV. So let's see what kind of role SDN can play in NFV. So in my mind, I think it can play a big role in the orchestration of the infrastructure whether it's physical or virtual when it comes to the provisioning of configuring those VNFs. Again, someone has to do that, right? It's not like I don't plug a box into the network. And even if I do, you know that, you have configuration running on that one, but here it's more like an ad hoc type of environment. Allocate and manage resources, for example, bandwidth. Yet to again, maybe have to move VMs across servers or even across data centers. Automation programmability, security and policy control, very, very important when it comes to NFV. And maybe, you know, SDN can provide that unique way to unify server control and management planning. Another area that I think that it's SDN can play key role is the service chain, which is exactly the forwarding graph that I talked about before. Again, you need someone to essentially direct those flows to the NFVs. And most of you are familiar, obviously, and you know, you work with OpenFlow. If you look at the OpenFlow suites, you know, then, you know, OpenFlow can be one tool assessment to do this type of traffic thing across the NFV network. The other important thing is being able to characterize traffic flows. So if I know that the flow has been originated from a mobile user, that might be important in terms of handling that flow within the network, I think that would be key for us. And when you look at the end-to-end type of scenarios. So NFV, again, has this dynamic environments with, you know, I think, you know, provide that nice logical map of the network. So I think that that can become handy. You will need to set up virtual networks, eventually, in an NFV network. So we think, again, STN can play a role here. And this can be ad-hoc and on-demand essentially in virtual networks. We may have to extend the mass orchestration to include network management. Again, you know, there's a question mark here. And now, when it comes to actually, you know, traveling those, you know, STN and NFV together, I don't think it's gonna be that easy, essentially, because you have to deal with, you know, environments which is like virtualized and non-virtualized, right? And so if it's a virtualized environment, it's easier to integrate STN, but if something which is not virtualized and have legacy equipment, you know, that's gonna be a bit of a challenge when it comes to at least STN. And also what happens if you have to run NFV across STN boundaries, right? You have an STN domain and not an STN domain, but you essentially want to run NFV across these. That might be another area of research. So but that's everything that STN still can enable and simplify and automate the implementations of OVNFs. OVNFs. So an apologies if you guys don't agree with me on this thing here, but that's like simplified version of STN. You have your resource, hardware resource at the bottom. You have interface and protocol running between the STN layer and on top you have application services, functions, utilities, anything that runs essentially on top of your STN control of the plane. And you have the different APIs because they're very important obviously to provide the clue between different layers. NFV is the reference multi-agent before. So if you look at an STN based NFV, maybe you have something like that which is much, much different than the NFV picture. The only thing here is that it have the STN controls perhaps part of the management space. So we think that at least in my view you got something like that can be integrated here and you still need those APIs in the basis to run in your infrastructure. Okay. Again, we can discuss that, but I don't think anybody disagrees with that. I think this is something that we have essentially adopted in NFV but we don't have yet the details of how this is gonna be implemented. Open and working NFV as we're looking at different things and different open efforts as you know, open is being used and abused today in many contexts. So when we talk about open networking, okay, we need to answer what should be open. So should we test the open source? Which is the set software? What about the design, the hardware? As you know, there are like efforts going on within the OCP project, the open complete project. Open standard, that sounds like an oxymoron because the standard is a standard, like there's not open and closed standards, but what I mean here is maybe something can start as an open effort in terms of standardizing and then it can lead to a standard that can be adopted by one of these other position bodies. Open interface, APIs, open SDKs. So in my mind, if you ask me, what should be open, how would you define an open networking system? I would probably say that it has to include at least two of these. Two of these, you know, should make an open. You can say only one should make an open, but if we want to be a little bit, you know, stridging about it or a little bit more further about it, I would probably say at least we need at least two to present, to qualify as an open networking system. It is important to have an open ecosystem behind it that people can call us and say, you know, contribute into this. It's very important that anything which is open is not controlled by a single package. So that's why that's very, very important. The captain of software and hardware, essentially that's what an open and graphic system is. The benefits and this is stuff that I guess you guys know about. The important thing here is the modularization because now I can choose those different pieces one should segregate the hardware from the software. I can, you know, customize my system and I can get the best upgrade for different components whether it's software or when it's hardware. You know, you have different things going on today. You have, you know, the bare metal switches that being open in the market. Then you have bigger strippers providing the software. You have cumulus providing the software and so forth. So we see this kind of movement happening today in networking and, you know, I think this is good. But let's see what that's going to be. Reduce cost obviously because now you can customize things that's more granular. And the other thing for us is the flexibility to be able to upgrade when we need it because things are running in software, right? So if I don't like something or something happens to that company, you know, I can, it's not going to be as seamless as it sounds but if I want to, you know, put another granular, you know, it gives me more flexibility. Issues again, how do you integrate all these different pieces and who's going to do this integration? In fact, your question, it's not going to be us as operators, so I don't have the skill set to take, you know, the bare metal switch and the software and say, oh, I'm going to put those things together and run these. We have perhaps to rely on third parties to do this, make sure, this integration. There are also other issues involved when it comes to at least the current environment whether it's the higher availability and SLA's and all of that nice stuff that comes when you're with a carrier including regulation, security and so forth. I'm not going to go through that here. The one thing I'd like to point out here when I was like working on this slide, it just occurred to me that the virtual switches actually would have to play a big role when it comes to this type of environment. And there is an invention that is because when I talk about service changing I think we have only about 10 minutes left about, you'll see why I think that's going to be very important. Okay, so this is the same architecture again. You can see how the different open efforts map into this picture here, you can see the honor system in the dedicated hotel, it also be done here. In open stack, I think open stack still can play a big role in this picture. I think open stack is the next slide. Now we think about open stack for a long time now and so from a few picture, open stack fits into two areas. One is the area where it actually is used for managing the virtualized infrastructure which is exactly what happens today. But I think also there's a huge potential for open stack to play a role in managing and orchestrating the VNFs themselves, the virtual enterprise themselves. And actually there was a summit last week in Atlanta and they actually talked about energy with the context of open stack. Again, it can be extremely important in setting up those multi-final networks for energy, resource management scheduler, I think that's important. And the one bullet here that I throw here is that maybe open stack can become the open distribution for that service change. The risk here is that once you go into this service change, we see different efforts from vendors today. So let's, you know, company FAA says, oh, here's my service change solution, but it works only with company BC and D, right? But if you have a VNF from company E, how do you make sure that this can be planted into that service change? So I think in my mind at least, like open networks can provide the service you can get. And obviously, some vendors won't like what I'm saying, but yes. Why did you like that, I mean? Technically, if you put a network function into a VM, right? It doesn't matter what the VM is, right? So why is company is service changing solution not working with any VM, just BCDs VMs? Well, ideally that should be the case, right? But I can guarantee for sure that this is gonna happen, right? So let me talk about service changing and we can discuss that because I have a few slides of service changing, so we can. So ideally that would be the case, right? But you have to have the right interfaces for that. But let me talk about service changing and I'll come back to that. So the other thing that really comes up a lot is the network as a service. So once you move everything into software and you can see that this can run on VMs somewhere, what people call cloud today, that opens up opportunities for service providers to offer things as a service. So that's the, so network as a service comes back, we can offer, so we can offer slides from the network to third parties. And the other thing about OpenStack, I think it has the distance of APIs and I think that's what really makes the feeling to connect. Okay, I think I'm gonna skip this slide because we're running out of time. Let me talk a little bit about the research and then the last topic I have is the service change. So, because one of the reasons I won't talk to you today also is that we're coming out with a number of research topics and these things stand for, we hope that some of you might be of interest to view. So we'll have a list of research topics that we announced and on our website. And that includes everything of course, that is a potential area of research, I mentioned service training, the orchestration, algorithms, and then controllers, I think controllers for NLP, traffic steering and dispatching. You have to look whether it's a pure personalized environment or a hybrid environment, performance studies and that goes back to the issue that I talked about in the very beginning, I'd like to see where you can compare apples to apples. And what are the research requirements when you move things to the end, no time back gets, any latency measurements, optimization techniques, system bottlenecks that people might discover. So, going back to the question, why haven't we done that? So, what has happened today is that some of the projects have been independently done performance studies before starting actually NLV and they're welcome to see themselves. I heard that these studies ourselves within Orange, they were able to see the benefits of moving the vision into a individualized environment. But I've not seen a concrete thing yet, whether it's under Etsy or by a vendor that says, this is the hardware solution here, the box and we can move things into VMs, you need that many VMs and these are the requirements and this is how much it's gonna cost you to deploy this service. So, when I used the word for a small company right here, one of the things I used to do back there was a use case. So, when we need to move to a business use case, when I have to move to, when I'm trying to deploy new technology, we have to work with the numbers. Okay, does it make sense to move into this technology? And usually also, some of the things involved in terms of returning first. Why don't the people who do the 14, 15 POCs, why don't they do that? I mean, wouldn't that be the very first? Right, so no, because firstly, you have to prove that something works and once you prove something works, they say, okay, if it works, okay, does it now make sense to do it? Could be the other way around. It could be the other way around. I mean, the part of, does it work? Right, but how do you know that? Yeah, but at first we have to make sure that something works, right? When something works, I say, okay, now I can move things into VMs. Accuracy comes up, okay, how many VMs do I need for that? So, but I mean, it can be the chicken and the egg. You could have started saying that, okay, let's do the economic. So, as I said, one operator, I think it's public, it's telecom, they've done performance studies prior to, to the bulking and they show that there are some benefits, but for me to be convinced and say, you know, the question is, it's not whether I'm gonna be saving anything. The question is how much I'm gonna be saving, right? It's gonna be 30% savings. It's gonna be 10% only 10% savings or it's gonna be dramatic as 80%. So that's, and again, it's gonna be very, very case specific. When you look at these different use cases, you know, the CDN will have different savings from, you know, from the EPC or something else. But you have to think that these are things that we're still evolving, right? We have vendors coming up with our social solutions, so we try to plug this in and see what it leads us. Okay, that's the cost-benefit analysis I talked about. Again, this is, and our security is very, very important. Business continuity and disaster recovery, you know, all these different areas. Consolidation of BNFs, algorithm for net BNFs, complexity, energy efficiency, service assurance, and maybe, you know, my vision is that I might be able to come up with new BNFs, visual algebra functions that we couldn't have done before for whatever reason. That's what I hope that one day we'll be able to achieve. You can find more information on our portal, which is not a very friendly portal, unfortunately, but there's a link that goes to NLB research. Okay, so the last or last but one topic is service chain and service insertion. So in a service chain in which environment you have, you know, the physical switches and also you have the visual switches that connect to the V-apps, right? And you have these service chains resented here by traffic flows. So one block can test the visual firewall, the road balancer, the deep packet inspection, the PCDN and so forth. Another one might test only the firewall without having to go through the road balancer. But in this picture, what I show is that each of them has to test the visual switch, right? It can be a visual, I mean, it doesn't have necessarily, but I don't think we'll be able to send, you know, to be able to link those, right? You have to go through the visual switch, right? There's no other way to provide direct connectivity. So that's why I think that the visual switch, you know, can play, it's a very important production of block in this architecture. And again, it's a visual switch, so you know, it can be any software tools on top of that to support the things like what the service, traffic monitoring, service assurance, all of these nice things. And monitoring, no. So, and the other thing I show here is that, it's not that visible, it's that all these different instances of the same virtualized network function, they have to form a virtual network. And because now different functions are sharing the same infrastructure, right? The same service, right? And same network. But somehow you need to provide traffic isolation. And that's what I think virtual networks become very, very handy. Again, how you create that, there are like different ways to do it today. You can use virtual network overlays, and targeting approaches. Maybe you can use metadata to essentially tag the applications. And also what you can do is that the policies actually determine the set of the chain order. So not everyone has, and this is the added flexibility of NLV. Now you have everything virtualized, you can define your own order of how these things are gonna be changed, right? In the past it was against static, one box connects to another box. Of course, you have, I mean, if you want to connect them in a different way, you have to send somewhere out. But now things are virtualized, you can connect them any way you want. And that opens up the, what I call here, programful service chains. You can actually make this in a programmatic function. And then you can, you know, you can, you know, software, you can do branching loops, whatever. Okay, so, virtual suites are very, very important here. When it comes to redundancy and disaster recovery, you have to wonder, you know, if a virtual switch goes down because, you know, it's running on a server, you have to say, what is the redundancy? What is the plan in case something goes down, right? So do I need to make a stateful architecture or has it been completely staked? Again, this is an open question. I don't have the answer for that. How do you provide all these performance guarantees? And, you know, language and structure for this product, you know, service chain, we think that's another area of research in describing this property behavior, accounting for constraints, security, or it's a benefit and so forth. Okay, I'm going to skip that. What I'm going to present here is that you have, this is the current environment of three, you know, isolated networks. When you move into visual machines, they're running, you know, on a server on the cloud, they get the control plane, essentially, controlling these VMs. Let me skip that. For network virtualization, I talked about. What I want to show you is the last thing is what we're working on in our office in San Francisco. So we're working on a VPC test, the VPC is the bolt packet core, which constitutes the mobile packet core for the LTE architecture. So this is the architecture for the UPC. So there have been some efforts around to virtualize the entire architecture. So these are like different boxes, like you see the packet gateway, the service gateway, the MME, all these are like different boxes running in an app today. So there are efforts to actually virtualize all of these boxes. So once you virtualize all these boxes, you virtualize the entire architecture. The interesting thing about this, this thing here and why I presented it is that, there are two approaches you can do that. So one approach is what they call medicalize. So you take one of these boxes, right? It could be the MME, mobile management entity, and you can say, okay, I'm gonna map that particular box into a server and that function is gonna be running on a number of VMs, right? And that's what you see here, right? That's one server, another server, another server and so forth, right? And it's running all these different VMs. So essentially a physical box is mapped to a VM that actually mutable VMs to be exactly found on one particular server. And that's binding efficient because it requires a many process to run these things here. And if you have, if you want to add capacity, right? You want, you have to essentially duplicate the whole thing here. Let's say you want to add capacity because authentication for whatever reason you want to have to educate more users, right? You have to essentially duplicate the whole solution here. That's why we think it's inefficient. There are other approaches, but essentially they say, okay, instead of virtualizing that, we can run things across. So these authentication functionality can run on many VMs that runs across my infrastructure, right? It's not one single VM per function. And if I need to add capacity with respect to authentication, all I need to do is launch more VMs. That gives you more flexibility. What happens here is that it sort of breaks down the EPC architecture. It doesn't violate it, but it breaks down in the way it was originally designed. So I present this as an example of, you know, of the benefits that one can get with virtualizing the network function. This is called node desegregation, right? It's sort of like mapping one box into a number of VMs running the same server. We just run these across a number of servers. Essentially, you know, you remove any boundaries between those functional boxes. So that's what people call the cloud EPC. And the last piece I want to present here, and we think we're actually a NLV and SDN meet, is that once the things are running in software, it's easy to integrate other software solutions. So one thing that we did with EM, this is back there, a couple of years ago was to use OpenFlow to do mobile traffic of floating, right? So we can use OpenFlow and to say, okay, I want that particular flow to be of floaties and into Wi-Fi network. So, and the active network discovery selection function is the one which is responsible for essentially identifying Wi-Fi's integrated, right? So if I have an SDN-based mobile traffic of float solution in the past, I have to go to Ericsson or Alcateluson and say, can you please integrate this software solution into your box? And since I'm orange, you know, they say, yes, I can do that, but it would take three years, right? To do this, you know, integration. But today, let's see if I have a vendor who does works on these particular solutions. You know, I can take their solution and plug it into my software-based AMDSN, right? Assuming that, again, the interface exists and I'll go back to your question whether, you know, so the answer is, hopefully, we like this interface and the server is saying to be compatible, but nobody can guarantee that, right? We don't know if this is gonna happen. So that's what I think is the beauty of when it comes to NIV and SDN and this is what, because both are software so it can easily, at least in theory, you know, integrate solutions into each other. So I think, you know, doing that, you know, I think this is a very exciting, actually, use case that demonstrates both, you know, SDN and everything, how you can use SDN in NIV and one. Okay, I think that's all I had. Any questions? Did I ask you a question or? So yeah, so the interface, so I know for sure that this is what happens. So when you get this management orchestration solution from vendors, these solutions, and I don't want to throw names here, they only work with particular software vendors, right? So, and we might see the same thing with service chain, but it's nothing today that guarantees. I mean, hopefully, you know, but we don't know what kind of hooks the vendors can put there, right? Because as you see, when it comes to these, what happens today is that anything who provides a hardware solution, they say here's also our software solution, right? And they want to protect their business. So we don't know whether that you might see partnerships for me, right? And so when campus service is chaining, we don't know how this, you know, because again, we don't know how to change those things. Yeah, whether it's going to be using metadata. So this we're going to use some sort of metadata, maybe whether it supports the same format without metadata. If it's more an open solution like if we use SDN to do the traffic steering, maybe it will not be easy, I don't know. I don't have the answer to how this is going to play out. Any other questions? Yes, I think that can answer. IETF has this group called Service Function Chaining. Right. It's looking at the same problem as what DNFG is. So are these two groups, is the HC group and IETF group, are they working together? What is the relationship between the two? So I don't know the answer to that question. I know that there's not a group XCIS. So what happens is again, we, as I said, we expire in January next year. So what we said that there are like different pieces here that fit in other organizations, so they can propose solutions. I don't think we work directly with them, but it doesn't mean that, so everything is one use case, right? It's not that we're trying to be the solution that we don't try to standardize that. So, and I'm thinking that IETF they're trying to provide some sort of standardize solution around that, I guess, so. We are aware of it, but we're not working directly with them. So are you feeding requirements to them? Is there any kind of? So, the only thing that we have probably so far in terms of requirement is that reference architecture, to be honest. So there are some gaps. Actually, we have something that we call gap analysis, but trying to define the different gaps on how we fit with other organizations. Obviously, IETF and the broadband forum, ONF, of course, are relevant to us, but again, this is still work in progress. So, yes, yeah. So one question. Do you see while you're writing this sheet from hardware appliances to software, the functionality which is within appliances to be breaking down to simpler components that scale individually? Yeah. For example, you're mentioning the virtual CPE, where the model that we have at home will be on a data center. So is this gonna happen as a NAT, a DHCP, a rate limiter, an accounting altogether? Or do you see having a separate NAT function, a separate DHCP function, and these things running parallel and you're doing heavy chaining on individual functionalities? Probably it could be either. I think mostly it would be, to ask this kind of thing, it won't be operator-specific because not all the operators are running the same home gateways, obviously. So some will have more flexibility than others. So I think it's more like an implementation issue. The essence is that we definitely want to, so we want to make that home gateway as simple as possible, with very little software that we can control remotely, essentially, because we don't want to be in the business of changing that home gateway every so often, like upgrading it or anything like that. But how is this gonna be done? I don't think it's within our scope, right? It's more implementation issue. Well, you had a question? Yeah, I know, so that is a good thing I'm running out of time. I didn't actually raise my hand, but... I came only here today for a year. So a couple of questions. You talked about disaggregation of NFB. I've heard people, like, you know, from my mysterious say that for many of these things, like firewalls and load balancing, you can disaggregate it to the point where they sort of don't exist as an entity at all, or just implement it sort of as an algorithm in the SDM control or functionalities is actually sort of implemented at the edge of the network, say, and you know, it's against an open V-switch. Right, right, right. Did you find that, have you looked at that, and have you found that to be the case for any of your entity, for any of your virtual network functions? No, we have not, but that's how, you know, that's how we started with SDM, right? When we were looking at SDM and working with open program, we, you know, we, in some of the cases, like we don't need those things fundamentally, we can actually integrate that into the V-switch, right? But what happens if not everybody has that V-switch, like, I mean, how do you make sure that, you know? And the other thing is that the VMs, when we think of running things in VX, gives you the flexibility of, you know, getting one of these instances, and creating those, you know, monitoring this network, it makes more sense to have this individual running on VX, rather than having any on the V-switch itself. Could be a real switch, though. For example, if you're, if you have your customers that open V-switch, you might be able to program them. Also, if you're, if like you said, the aggregation network or the simple office, you know, is the sort of data center kind of network, then you might have a whole lot of virtual switches there. Yeah, I mean, I think to me, to answer your question, it would be more a performance issue, whether that thing can escape. But in principle, I agree with you. I know that's why I said that the V-switch is the, to me, the most important block, because you can start integrating all the things. Yeah, yeah, okay, I understand what you mean now, which is, when you said the virtual switch is important, that's exactly what you were talking about, okay? You're not going to start with SDN, right? We're looking at SDN, which I think it uses for 5-1, for low-finance, if you're going to do that, so, yeah. My other question is, I just saw, I mean, I thought I'd kind of talked to the microphone last night with that, you know, and they said something really interesting, which was, well, I said a lot of interesting things, but one of them was that for Google's network, they found it very useful to, for Google's network, they found it very useful to extend the SDN to the data plane, to have programmable packet processing. And sort of, have you, you know, looked at that or found it, do you think it's necessary or useful? So, that would require changing the C-prime of the SDN to the data plane? Well, they were sort of stingy, as they usually are, about their implementation, but, you know, you can imagine that, you can imagine that it could be done a lot of ways, it could be done as something, you know, in a VM using, you know, existing APIs, like, click, it could be in, it could be done in, like you said, an FPGA, it could also be done in something like, a network processor, you might have different implementations of varying sorts of hardware, but perhaps a common API to control them all. So, that's sort of the thing that we're seeing here. No, this is data plane processing, not, not control plane, you know. So, an example of data plane processing that, that carriers do is, you know, they compress web pages or something like that. You know, they compress traffic, or, you know, compression and encryption, you know, lots of, I think there's lots of, you know, counting measurement. I mean, DPI sort of is certainly data plane. Right. So, my question is, you know, have you thought about, you know, data plane, DPI's, I mean, trying to extend, extend the SDN so that you can see the data plane so that you can write things in sort of an orthogonal manner than by working on different platforms? I don't give any of it myself. For me, lately, I mean, when I was working at SDN like three or four years ago, and that was one of the things that I did when I came to SDN because it's all about software at the end of the day, how you can make things to around them. So, if you do that, you'll find a solution. I don't see anything attending all of it. Actually, for now, we don't even focus on the data plane, we're focusing on the data plane. Yeah, the interesting thing, they seem to be implying that for their use cases, there were a lot of things that were, you know, they weren't, they didn't scale, they sort of were pretty inefficient to implement in software on a VM. Right, right. But they could be implemented efficiently in some sort of custom hardware. Yeah, that's a good point, actually, because if you ask me today, whether, you know, because we said that these should be running on standardized IT and servers. If you ask me, is that going to be the case? Maybe not, because some of the functions may still require some specialized processing and an accelerated thing. But that's why I want to do the performance things first, right, because the performance doesn't match and say, you know what, they can do that, but maybe you're not going to get this much. Then, I've come with like natural non-core reasons that didn't specialize hardware for that. So, yes, the answer is yes, yeah, I got it. Okay, let's wrap that up. Thank you, everyone. Thank you so much.