 All right, so good morning, everybody. My name is Deng Hui from China Mobile. And I'm Chris Donnelly from Huawei. Yeah, today we are going to present you the one open source project we are proposing today. Before I get started, I would like to claim because this open source project hasn't been officially formed, and I think most of you have already heard, we are going to finalize the deadline about the agreement around June 1st. So what we are discussing here is not officially signed by, I mean, not constructed organization. So what I came here is mostly what we are discussing today, and we came here trying to invite people like you to consider, to help us, to join us, to work together. That's the purpose we are here. And so we are going to present firstly is about why, why open home. Today in Telecom Operator Network, we already had lots of deployments, especially in the data center. We also have the SDN for the overlay controlling, and also we have the optical, metro, level two, three SDN deployment in our main network already, and also even in the outside side. So all of the SDN has been deployed, then some of us will consider why we, why not we can use our resources more efficiently by the virtualize them. And we, you can see every step we can try something virtualization, then some of the application you can see today, not all of the Telecom vendors are really, would like to work with us, with operators about the application to be virtualized. They just move the ATC based software directly to the x86, excuse me, platform, but that won't work. So we need a cloudified solution for the software. That will take time, but when we do the, when we want really deploy it, so you can do the step by either first and fee or later SDN, you can do the other way, the first SDN or later and fee. But when you do the end-to-end substation, you do need one layer on top of them. That is the unified SDN and fee orchestration. So most operated today's network, we call it hybrid network. The reason is very simple, very simplified example is like a channel mobile, we deploy, I mean we spend like 25 billion US dollar every year. So all of those expenditures, we call them the legacy. Because when you do the SDN and fee, they don't support it. You have to consider to the telecom operator by supporting all of them together, including legacy, SDN and the virtualized environment. So continue, if you people, you can look at the center, lots of people are proposing like supercontroller or global or demand controller. So we are thinking the controller, the design, the purpose of the controller mostly is about the resource abstraction and also pass calculation. That is the principle of the SDN controller. But when we're talking about the orchestration, Austria is doing the service resource orchestration. So that requires you to have to interwork with the legacy, OSS, BSS, even apps. So by some people are thinking, so why not we put together about the pass calculation together with services and resource orchestration. But my challenge, my argument will be we have to decouple the service with all the resources. That's the beauty of the orchestration, I'm going to talk a little bit later. So the orchestration is, it looks like this, they have to cover in the telecom operator, you have to go from the multiple domain, multiple layers and multiple windows. So that's the difference between the operators network compared to the distributed, I mean the legacy OTTs network. So some people are thinking, okay, so today why not using the enterprise solution directly to the telecom. First of all, it doesn't happen yet. There are multiple reasons. Here I just gave a very simple reason to help us understand much easily. The OTTs network, the enterprise network, they are just like a data centers distributed. You can put into the New York, you can put into Tokyo, you can put into the Paris. So all of them are flat network. It's totally distributed and equality of the AIO data center. But when you come to the telecom network, we are the different. The 3GPP has designed the EPC radio, so those architecture is a heretic. If you go to the broadband forum or cable lab, so whatever they are doing, they have layers of the architectures. So you have the either wireless, radio, fiber, Wi-Fi access, and you have the layers gateway side, and you and you have the core side for the applications. So this kind of design architecture of the telecom, it's totally different OTT. So if you compare with that hierarchical architecture of the telecom, then you can look at to your right side is the complexity of the carriers. The carriers were supposed to provide the connections for the subscriber. So we are assumed to always provide the connectivity to the mobile phone, to the broadband home. So that is what we are doing today. But to do that, we need to build a very complexity of the network in between those services. I mean, if you put service into the data center. So this complexity of the connectivity of service is different from the between the enterprise and telecom operator. I can see this is the really difference in my heart. I mean, we have the optical layers, there are different transitions. The OTT, they are just purely distributed, data center, you can do that. So we see this is the difference of the telecom compare with enterprise. Then we come to the enterprise continue to propose, for example, based on today's open stack, they are proposing like we are for manager or orchestrator. So they are today, I think I can see that it's mostly enterprise and free solution. But for telecom operator, we are targeting, it's different. We are targeting telecom and free solution. So we are targeting telecom and free orchestrator, and we are targeting telecom and free manager. So that is different from the enterprise part. So we have our complexity, we have our difficulty, we understand that. So we have the, as I said, I spend 25 billion U.S. dollars every year, then those things is not easy for you to change that. The people management, those expenditures, they don't want things to be, I mean, to be interrupted or to sometimes get something wrong. So they ask you, ask us to align with, in some sense, a scenario about how to align that, about legacy, OSS, BSS system, you need unified SDN, M3, API, you also need supported hybrid, like even VMware and open stack use cases. And so most importantly, we get you to a standard, we also need the information modeling. So that will help us. So I put the question mark here to let people think about that. But what we are doing is not just, I mean, like a baby stable, but we are trying to be revolutionary. So what we are doing is revolutionary, we are thinking, why not we do the OSS, become the open source software, that is from OS to the OSS. If you look at your left side, it's legacy, telecom operations, operation architectures. Each of the vendor today, they provide the proprietary EMS for their product. And probably either operate it yourself or you go through some other vendors to provide it, the OSS to management, all of this proprietary solution. So that is really hard for the operator today. So when we come to the SDN, when we have the data modeling came out, we have information modeling came out, then we thought, oh, this we are going to change. So what are we going to change? If we can put, we replace by the orchestrator to our legacy OSS, even the orchestration part, then go through this orchestration part, we can talk to the legacy resources of the OSS. And we also need to talk to the billing system of the BSS, even apps to management of the SDN and EMS legacy part. In order to do that, we think these are steps one, two, three. To your right, you can see we needed discovery and obstruction of resources. We also needed to define the modeling or mapping in top to the orchestration. So this is a really revolutionary work. But to do this revolution, to make this really happen, we cannot just make, I mean, the bloody revolution. We have to make a smooth revolution. Because bloody revolution, we are not happy the legacy part. So we have to think about how to do that. I am going to explain my vision, our vision about how we migrate from the legacy to the future of the SDN and EMS orchestration part. So open all here, we are representing this kind of revolution. We hope we can build a unified open source orchestrator on top of that. So this is quite similar. I made a comparison. Today's success was cloud computing because of the success of the internet. The internet become a success because of the simplified IP. Just because of that is the simplification of IP. That's internet going everywhere, going to the global. So IP has successfully to decouple the layer two or layer one, the infrastructure with the top layers of the transportation applications. But what orchestration doing today for the operator is the same. So orchestration is decoupling the resource infrastructure with the service layer. If we unified the service layer together with the resources, that we are not to let operator to your solution to the right direction. For that reason, we are thinking the orchestrator becomes a very important sitting right in the middle to decouple the services and resources. So open source, especially open O, is going to create a unified orchestration abstraction. So the open O has many benefits. I think people has already heard too many things. But here I just want to mention one of the points here is about the pre-integration. So the very important for the technical operator is you need to do the pre-integration. The time to market is not just, OK, I can run everything. Then time to market might be very short. The most important is you need to do something pre-integration based on the modeling. So that's where I save you time to market, reduce the complexity, improve your quality, security, and stability. So by reducing the integration, so what we open, the orchestration is mostly owned by the city manager. So by reducing the time for the integration, by doing something pre-integration, you will be successful to really help operate. So that's one point I want to make. And so coming next, Chris, you are going to talk a little bit about open O's vision. Thank you. Let's talk a little bit deeper about open O. And first, we'd like to talk about our mission in scope. This slide is from our charter document, and there are a lot of words on it. So let me just highlight a few things. First, our real goal is any service on any network across SDN, NFV, and legacy networks. And second is that we want to be model-driven, that we're going to support common and vendor-specific data models, and interoperability across different controllers, different VNFs, different VIMs, and different VNFMs. And as we was just mentioning, we want to reduce the customization and accelerate innovation in the multi-vendor ecosystem. So let's talk about our architecture from a very high level. We have an orchestration service consisting of three modules, global service orchestration that manages the end-to-end orchestration. And then SDNO, which manages connectivity services, NFVO, which manages virtualization services. And then a common driver layer supporting multiple controllers, multiple VNFMs and multiple VIMs, surrounded by common services and common tools. In a deeper look at three of the modules, the GSO, the Global Services Orchestrator, focuses on the end-to-end network service orchestration. It provides the unified service orchestration, both the legacy and the SDN, NFV networks under multi-vendor circumstances. And this is the part that will integrate with a carrier OSS, BSS systems, as well as in the future with new cloud-based provisioning systems with the GUIs and portals that are being developed. Next, we go into the NFVO, which is an Etsy MANO compliant NFV orchestrator. And this will manage the virtualized applications and virtual network functions and works on the onboarding and lifecycle management and resources for the VNFs. And the third component is SDNO, which manages connectivity services across both the SDN networks and across legacy networks. And if you look at these together, the SDN orchestrator, the SDNO component, manages the underlay, and then the NFVO would manage an overlay network on top of that. Right, so I think this page, this is different from what I presented last month in the open-air sandwich, because I really think this is important to let people to understand the differences between the legacy. So this is to your left side, is your today's operators network management system. On the top is the BSS. It's more like a product orchestration. And if you look at the center, this OSS is doing two things. One thing is customer facing. Services, the other thing is resource facing services. And if you look at the Global Service Auditor, it's right sitting over there. And also, if you look at the NFVO and SDNO, it's sitting across both service layer and also resource layer. The Global Service Auditor is going to decouple the service to both sides, either the SDN orchestration or not also, but also NFVO orchestration. That's an orchestration layer. So then under that, you can have the resource orchestration by either now services or we have services defined under the bottom side. So this mapping, you can see, it's very important for people to understand why we design like this. So we are not saying we are saying like a legacy, but we are saying we try to make a smooth revolution other than bloody revolution. The smooth revolution means you need to, because today if you go to the telecom operators, OSS, it said, everything on my side, resource orchestration, resource is already depository. I have all of the information over there, why you need something more. So what they are missing there is they do not have virtualized information with virtualized resources. So for that reason, for the orchestration, you need to talk to both legacy resources and also the newly built virtualized resources. But how can we do the smooth revolution? I didn't draw clearly here. I just want to talk already verbally. I mean, you can do by SDN orchestration to connect to the legacy EMS to get the more and more legacy resource into the orchestration layer. But because historically all the legacy resources go through the legacy OSS side on your left side, they will not go top to the OSS, then make a right turn to our orchestration. So if you do revolutionary, you have to do something by bypass of the legacy OSS and to our side. So based on this kind of migration, you can step by step migrate the legacy resources to the new OSS system. So this is the vision. We can see how we can really deploy these without making the bloody revolution. To let operators can really deploy SDN and free based on the orchestration, I mean, these kind of new architectures. That's what I see. So I would like to present this to explain why we operate thinking is important. And continue, I think everybody has already agreed, because the legacy OSS-BS is not success. The reason is modeling is not success. But today, time flies. Everything has changed because we have the modeling over there. We can do like a unified source creation provisioning based on the normalized modeling. So that's, I think I do not need to spend time with people sitting here. We are all agree, modern dream framework. The one of the other important thing I would like to mention for the orchestration is, so most people are talking about the high availability, carry greater capability. The virtualize, for example, OpenStack doesn't support computing load high availability today. They only support controller. One of the same important is also working on to try to help to improve that. But for those who carry great capability, we have seen you can do either wait until the failure really happened, or you can do something prediction before that happened based on what you learned, the analytics, the data. So that's very important. We are not going to wait until, I mean the machine learning or data mining, this kind of technology will help us to improve, to help us to really deploy the virtualized environment in our network. So this kind of, we are building this by double loop. I mean you can do either like a real-time response or a long-time response, different kind of looping technology. You can set in your policy to reconfigure your either your virtual infrastructure or your VNF management by kind of healing or whatever. And so in order to do that, you need to collect to monitor, not only just the virtual infrastructure by either here or open style. You can use like mononascar or telemetry or a centimeter or whatever. But also you need to collect the information from the VNFs, so those information will help you together to build your analytics tool to change your policy, to try to help the virtualized infrastructure without really in the last time, in the last minute to face in the failures. So I see this is really the important for the virtualized environment, for the open style, for the NFESDN part. So we are also working on this part. And the other thing I also would like to talk is about the source front-end training in the open all we are considering today. I give one of the animation to let you help us to understand and what we are doing here. So firstly we have the customer order, billing system is always there. That's the most important part for today's operator. We are making money from them, but so we cannot just without consider just do our authorization. So we have the product customer order production sophistication. Then we put this down to the service sophistication. Then we have the VM falling graph chain over there. Then we can do decoupling either by, firstly goes to the NFU authorization. We have VM falling graph. What we believe is that we need a VM for service function training engine is sitting inside the authorization layer other than VM for manager. Because he has the view, he has the global view, the vision of the network infrastructure end to end. Then later you send this one the decoupled service front-end training to different VM for manager. Then you different VM for manager. We are continue to deploy service front-end training to under the VMF. Then you simultaneously you ask as a string controller to configure the policy on the classifier even over to the open with switch under the service. Then you can really build the end to end service function training. So this is the really take on service function training. We are rely on multiple vendors as than just one vendor to deploy a service front-end training. So that is the reason we put service front-end training engine in our authorization. So this I would like to highlight as well to help you to understand. Yeah, so next use case please. Chris, you are more familiar. Thank you. Let's put OpenO into practice. We've talked a lot about the theory behind it and the architecture. Let's explore a virtual CPE use case. So the scenario is that the customer wants an internet access service with 500 megabits per second with firewall and NAT services. And we need to put this together in a virtual CPE solution in the overlay network service. The catalog registers that the customer gets 500 megabits per second internet access with the firewall and the NAT. In the enterprise case, we understand that there's also firewall and policy control. And then in the data center, we add a service chain adding the VCP and VNAT functions. And finally in the underlay in the base access network, we need to complete a circuit across a potentially complicated network with multiple classes of service and hierarchical QoS. So using OpenO, we can put the customer information into the design time catalog and pass that off to the global service, GSO, which provides the overlay network service and understands end to end how to build the service. It also keeps the end to end topology for the service. Then it talks to SDNO to bring up the underlay to set up the network connection over whatever access network I may be present, whether it's legacy or whether it supports SDN. And this could potentially talk to multiple EMS systems to talk to legacy equipment. And then one or more SDN controllers, potentially you would have multiple controllers, one for your access network and maybe a second one for transport network, just for example. Next, we need to set up the service in the enterprise. And so we use the NFVO component, which is responsible for the overlay service inside the enterprise. It has the topology for the enterprise and the forwarding graph and also sets up the firewall and policy control VNFs. And then also in the data center, we need to set up yet another topology map and forwarding graph and maintain the VCPE and VNAT functions with the appropriate service chaining. And then global service orchestrated to the GSO stitches together all the different components to make one end to end service. So we'd like to invite all of you to join with us as we build this system. Open O is a Linux foundation project. We are planning to officially launch on June 1st and we fill a gap between the infrastructure and OSS layer. So you can see where we fit with various other Linux foundation projects that Linux foundation has been up to this point working on performance functions on SDN controllers on NFV and of course on the operating system and containers on top of that. The one area that hasn't been filled in is management and orchestration and this is the area that we're focusing on. And we play well with others. We will be working with many other open source communities including OpenStack, also OPNFE and Open Daylight and ONOS just to name a few. We are building an Etsy NFV compliant Mano with the NFVO component. We plan to integrate with a variety of VNFMs including Tacker and we are also looking at other standards organizations such as potentially MEF with LSO being able to work in our community. And we will be working with OPNFE to make sure that we appropriately integrate in with future offerings. And we also are interested in interoperating and integrating with Tacker. So our relationship with OpenStack is that we intend to provide customer-facing services through OPNO, through the Global Services Orchestrator piece and also connect with OpenStack for VNFM and VIM services but keep end-to-end services in the GSO module and build our own NFVO and also connectivity services through the SDNO module. So specifically we're looking to integrate with Tacker for the VNFM and with other OpenStack components, Nova, Neutron, Cinder and Swift for example for the VIM working through OPNFE. And in our scenario we'd be looking to Tacker for many VNFM functions including the catalog, VNF life cycle management, performance and health monitoring, healing and configuration just to name a few. And we'd like to invite you to join with us. We currently have 15 partners who we've been meeting with in the pre-formation activities. We are openly calling for founding members and we have a membership agreement and charter documents that we are happy to share and we will have an opening for founding members up until June 1st of this year when we plan to officially launch. And a few milestones on our timeline as I just mentioned, June 1st is our launch date. We plan to have a hack fest at the OPNFE summit at the end of June and we are also working towards a first release by the end of the year sometime in Q4. The community is still forming and we will make a decision on the final launch date in early June. And I think we have just a few minutes for a Q and A. If there are any questions, please line up at the microphones. It's challenging to see from here but it's easier if you're at the mics. Sure. Hi, so as an outsider looking in, I'm gonna have to play devil's advocate here. So of course you can build an open source version of OSS-BSS system that's fine with proprietary plugins going down to different EMSs and all that. But it seems like this architecture kind of promotes multiple resource orchestrators, multiple vendor-specific VNF managers, and multiple VIMs. And I guess from cloud, the whole point is that I have one uniform infrastructure that I can share and use across all different VNFs from different vendors. And it seems like I don't wanna run multiple open stacks that are vendor-specific. So how am I wrong? Right. A few things to start with is that the networking industry as a whole is still evolving. And there are multiple SDN controllers, for example, Onos and Open Daylight. And different operators are selecting different components. So we wanna be flexible. We wanna have a common driver layer so that we can support whatever a particular operator needs but providing a level of abstraction so that you can write a cloud application once. And just say I need a network and here are the parameters that I need and not know what the SDN controller is or the VIM underneath it. And we'll handle that for you. So it's really about flexibility and choice for the service providers. Yes, so I totally agree. I think also there are already lots of the cloud has been already deployed. So they are not based on open stack, it's already there. And also VMware has marketing shares in the operator today is already there. We like the beauty of the uniform, right? So, but to be realistic, we have to face in the reality. We need to handle this. Otherwise, the people from not what many people say, I don't want to do this because you are not really migrating. So they want smooth migration. Please. This is Lushu from Comcast. I think great new presentation. We also share a very similar vision approach. One challenge we have is you talk about the unified service creation. What's your take? I think we have, the challenge we have is how we unified analytics. And you also have a slide, top of analytics. I think today, I think each component, they tend to have their own analytic. The challenge is how you unified that. And then if you can unify, the second one is how you can tie the unified analytic with your unified model when you do the service creation. Yeah, I think very, very good questions here. The, exactly, I mean the, we are designed this by messaging bars, right? So analytics is just one model to plug on the messaging bars. So analytics, they are not just saying you can only do one of the learning through the analytics part. You can, based on different use cases, you can call in different, the analytics. I mean, analytics is tourist might be, you can either, you can even adjust the weight, that adjust those features, not necessarily. So what I can see is we have multiple purpose use cases for the end-to-end services, but we have to design this. So we are not always, so you know, we have manager have his own, I mean the analytics to do the auto healing, whatever they can prepare a solution for today. So we have vendors, but we are providing the kind of tour for you if you really like use that. And then you can, I mean, calling different from different module by different parameters, different features together, other than just using common analytics tours, right? So that's analytics module can support a multiple use purpose or they have multiple algorithm over there. It's not always just like a neural algorithm or neural network algorithm or you can do the logistic, statistical algorithm. There are many choice for you to do that. It's just tours or module that we are implementing over there. Do you take an approach? You want to aggregate all your analytics, especially if you're going with a big data approach. Do you also aggregate all the data into another central location where you still kind of utilize the individual analytics and then you'll kind of harmonize and distribute in that way? Yeah, so right now we are just designed like a double closed loop. It's more like a major coverage purpose other than the big data. We do have big data on somewhere location areas. So that could be, so I think you are talking whether we can align these to combine design or new, I mean, more wider analytics. That could be possible. But I think we need a more contributor. We are just the beginner of that. I think we still need, for example, if common cause are interesting, we are very honored to work with you about that direction. All right, thank you. Thank you. Thank you. Hi, I have a question that since you mentioned Taker, which is the OpenStack service that folks we support. So do you think there is some obvious gap between the current ability and our requirements or something can improve? Yeah, honestly, I read your newly proposed future vision. So I can comment on today. We treated that as a VM for manager, but I still think that there's still a big gap about what we are expecting. And especially when we compare with others as a VM for manager, still I see there's a distance. And I presented a couple of times, even OpenNow Summit, I mentioned the many things over there. Even today, I also mentioned four points over there. You can look at it there. And so because that's already presented there, then I hope you already understand them. Yeah, sure, thank you. You're welcome. Thank you. Brian? Yeah, hi. So this is gonna draw a thread with the previous comment about analytics. I saw on the slide you had EMS, right? Which I assume means that for legacy applications, right? Things which aren't virtualized or things for which it's so complex that the vendor has to provide you an EMS, you're gonna accommodate that. I mean, I think that's a reality. That's a brownfield problem, it's a reality. But what we need to be driving to, I think, and I would suggest that we work on this in OPNFV and across OpenO, OSM and whatever, is ensuring consistency for V and Fs going forward as much as possible with the common analytics capability. So to that point, I mean, right now, for five different products, you get five different monitoring solutions. Even the exact same spec, you have different semantics for the exact same values in those specs. And it's really not scalable. And especially in a virtualized world, we have to converge. So that's one of the reasons why we have a project proposal in OPNFV, we're gonna do on open sourcing part of our ECOMP framework, ATT's ECOMP framework, specifically focused on a consistent spec and an actual code for collecting analytics directly from VMs, right? And then publishing up to a collector which behind has a Hadoop data lake then you can do whatever clever things you wanna do above that. So I think that's the sort of thing that we need to do at this point as we start these projects to make sure that we're driving convergence from day one with regard to analytics. So is that the sort of thing that you're thinking that OpenO is ready to collaborate on between OPNFV and other solutions or other projects? Yes, what we're trying to do is build a common framework and then also collaborate with the rest of the industry on common information and data models to facilitate exactly what you're talking about is a common data collection from all of the various BNFs and then being able to act on that as is appropriate for the service provider environment. So we're just getting started and that's something we're building to but this is something that we're building into the architecture from the beginning is the common framework and the ability to plug in different components as the industry coalesces around particular functions. Okay, we're gonna donate that into OPNFV. It's gonna be the spec, JSON-based spec for VNF, syslogs, whatever data coming from the VM and also code for the collector and the agent that you install. So basically out of the box it'll work and we can take it from there. Yeah, so there's three interfaces on the latest part. One is from EMS, the other one is from VNF, the other one, the last one we found in virtual infrastructure, those need to be aligned. But yeah, so thank you. That means the last one we have running out of time. I think we're out of time. Perhaps we should catch up in the hallway after the session. So thank you. Can we talk offline? Okay. Thank you.