 Okay, so just in interest of time, I think we'll kick it off, first some advertisement under the name of the sponsor, anyone who's in the room here who has the Intel Passport could get the Passport Stamp later on and told many good things that can happen after that, so don't forget that. Anyhow, this talk is a community talk on a subject that is pretty hot for the OpenStack community, a little bit hard to find the room, so we had a problem in this room earlier as well. We have four different companies actually sponsoring the talk, so I'm very pleased to have Tobi, you want to introduce yourself? Sure, my name is Tobi Ford, I work at AT&T responsible for the cloud effort underneath our NIVIA work. And Chris Wright is actually here but probably also have issues finding the room, we just met earlier this morning and Diego is in another event in the US that is taking place this week, so he's not here but he's also supporting this talk about history and myth of early Middle East with the Tower of Babel and we'll talk a little bit about technology too, so this works. So the subject is really about the manual layer, that is the layer I'm going to stand over there because the light is a little bit less troublesome here. The manual layer is that layer that from the Etsy model is in charge of the orchestration and management of the VNFs. VNF could be thought of as a group of virtual machines that are collaborating in relatively tightly coupled manner as compared with your favorite or known cloud model that you have in OpenStack, just simple cloud. And as we talk we have grand entrance into the room by Chris Wright here, so we are just starting, you could introduce yourself, there is a mic over there and we'll continue. Hi, I'm Chris Wright, Chief Technologist at Red Hat, still working on finding my way around this labyrinth and great to be here. So we're talking about another labyrinth right now that of Mano and with Mano we have few roles that that layer is trying to fulfill. On one hand it's a critical component because obviously you don't have NFV deployment unless you could place the VNFs in a way that they fulfill whatever was the SLA that you wanted around them. And on the other end we need to look at where we are as a community and that has to do not only with OpenStack but also with NFV as a phenomena as well and then see how we are doing as an industry. And what you see is that we have few requirements that may be presented best by Tobi here and other operators as what people would like to see from NFV and from Mano and the way Mano may interact with OpenStack and other layers. But also as the way we all analyze and understand the technology and so we need to have the service requirement really match or better said the other way around we need the devices, the infrastructure that supports that better match what the service requirements are. Basic things like automation that are kind of almost there today in cloud are going to be a little bit lacking here. The topic of network awareness that was not all that critical for you typical cloud model in a typical cloud model and we'll talk about it later in this talk. The VMs are loosely coupled many times you don't have that much IO network resources that are required. The data plane on the server is not heavily engaged so whether you understood the network or whether you simply look at that as oh here is I think I'm provisioned for whatever bandwidth and I'm simply deploying one. It's going to work is something you want to challenge over here. Issues of failure, service predictability, how am I doing? I want to not only be able to detect failure and do that in telco time rather than in what today OpenStack allows you to have. I actually want to be able to pinpoint that remember as telco we are moving from a model where you have physical devices and so if that service is broken it could be one of those physical devices to a model where we have multiple VMs distributed around some infrastructure. What is the problem? Is it this piece of my VNF? Is it the network connecting them? Is it some extra load? I cannot tell. And you guys please jump in any time you feel like. In addition to these items I mean also this is not just for one site. Typical OpenStack kind of history is about one location. For us this is hundreds of locations and having to manage across the resources across that type of geographic distribution not just initial placement but the life cycle management as well. So that's another part of it is making sure that we get the best utilization out of the assets we have and that involves a lot more than just what the scheduler is able to do today. Other problems has to do with high availability, with scalability. We have few issues with those. Not only don't we really know what layer is supposed to do that, is that something the VIM or OpenStack as an example should be doing? Is that a VNF manager? Is that higher up in the manual? How do we really avoid duplication of those functions? Security goes without any other words. We need to have specific because security is definitely a very loaded term. We need to have specific services that really match what we need. We are really focusing mostly in this talk about steps, concrete steps that we could take as a community over here. So I'm not going to spend equally amount of time or equal amount of time talking about all of those challenges. We really want to focus on some of the critical aspects mainly around information models, data models. So when we look where we are to finish this kickoff slide, different players in the industry are doing different things. There are building silos which is not exactly a good match with what the telco operators would like to see. And it's not necessarily also the best model to move us forward and make NFV happen as soon as we can. We have all sorts of legacy that we need to deal with starting from the OSS, BSS, but also physical devices. How do we actually make sure that we integrate them because nobody is starting completely from scratch? In addition, also we won't want to ignore the long history in the IT realm of working up management orchestration, monitoring policy type tools. We want to be inclusive of that history as well as the telco's history with OSS, BSS type systems. So what we would like to suggest is that really what we are all after and we hope that that covers all different segments of the industry is we would like to see technology that could be deployed on a large scale, not limited to one data center as an example that is standard based and also very, very importantly cost efficient. There is a need, we have all seen those graphs where the telco industry reports, hey there is pent up demand for services and well the cost of the infrastructure is not keeping up with it, part of the reason why we are moving in this direction. Can we all simply help make that happen and happen soon? So in order to get there, there is a need for us to work together and this talk is going to be about some of those requirements, propose some directions for the manual architecture as well as what OpenStack itself can do and how can we all move forward together. Some history lessons as I said this is not only about technology, it's history too. So we all remember some cases where there was not really the most beneficial conversation that didn't really help any technology move faster forward and that probably something we would all like to avoid. This starts as early as the days of electricity where we had two camps fighting for should we use alternate or direct current etc. We all know what happened there. We better allow a model where we set some baseline and people can differentiate on top of that rather than argue over the basics. So the next phase in this talk is about, okay so now that we are in OpenStack let's talk about some specific needs or some specific capabilities that we have that are not necessarily already fully supported today by OpenStack and how can we move forward and get them better supported. I'm starting with performance because performance was really also historically the first thing that the industry did in order to see oh can we really deploy NFV on some standard high volume servers. Is it really going to work? But as we all know technology doesn't stand by itself. It also has to be based on financials that work for folks and so the performance really means that I could have enough horsepower on a given machine to allow me to get to a competitive cost point so that we could all pay less than what we are paying today and get more services rather than a model that cannot really support itself. So using servers were the data plane performance because we are talking about higher performance than what you normally find in a cloud. More network oriented, more packet processing, the performance is going to make a big difference for you. But we have other problems or other needs, not necessarily problems, think of them as opportunities. But in telco environment I would need to have support for different types of VMs that are working on the same platform if I want to keep my utilization high, if I want to keep my cost low. And now I need to make sure as I increase the utilization level the chances of different VMs competing for resources is higher. Therefore I need to make sure that I have better support for that. Again something that is not as pronounced in a cloud environment. Scalability is also different here. We have the question of what layer deals with scalability but we also have issues that have to do with the initial placement. Since a VNF is a group of virtual machines you may want to be looking not only as to how individual VM is being placed, the model that we have today. But maybe most of the VMs I have in my VNF are placed such that they could get their SLA all right but one of them is not or it's placed too far away, too many network ops, not enough bandwidth, etc. That's going to bring down the whole VNF and I'm going to be scratching my head or overutilize the resources which would allow poor packing which again is going to contribute to higher cost. And then when you migrate when a VM fails and yeah, you could instantiate another VM that is going to take the role of the one you just killed but maybe that's not running on the same infrastructure. Maybe that's a little bit too far away and so all of the sudden your VNF performance drops down so this is the notion of predictability. I would like to have a way to describe what I need all the way to the top, to the bottom and know pretty much with reasonable level of certainty that I'm really going to get what I just asked, I'm going to get. And there are other challenges as you could read on the slide. Okay, you jump in anytime. Okay. Front row seats are heckling. That's how it goes. So one little topic to focus on for a second and then we'll move on to the information models. One way we think about that from Intel point of view is these two arrows that you see, yes it's also on the left for you. One arrow is about exposing the capabilities of the infrastructure and another arrow is expected to come down and tell us what is the requirement for that specific element of your application of VNF that is on that specific machine. In OpenStack we are doing reasonably okay with exposing the compute. We have ways to go and exposing network related and as you'll see when you start really peeling the onion on stuff like service chaining we could do better as an industry on unifying our policies. We'll look later into some options to support man on top of OpenStack. We have too many options and none of them is exactly right. So as Goldilocks said I want it exactly right. So we'll see how we go. But specifically for NFV we need to distinguish between the model of the cloud where I don't know what platform I potentially go through. The hypervisor and the operating system and encounter those problems or overhead and then I cannot have tight control over my latency, my jitter, my CPU utilization etc. Two models that are more friendly for packet processing but that is not to suggest that the only thing we are doing is packet processing. I actually want to be able to pick the right platform for the right job. So let's now look specifically into MANO some of the requirements and some architectural options and specifically what does it mean to put it on top of OpenStack. So the first concept is the concept of flexible and modular. There are multiple reasons for that. What we see in the industry is that different components of the MANO layer be it a VNF manager, resource orchestration versus service orchestration and we'll see what happens with the information model. Starting to grow up in different places some of them in silos, some of them in open source. One of the ways you get a healthy functional collaborative open source community is by having your solution sliced up such that different people can contribute, you get best of breed rather than only one solution. There is ongoing work at Etsy actually that is in session this week to enhance the model of service orchestration that was not fully done by Etsy admitting to that fact in earlier days. Now it's the time to go fix that. So this is one area that we probably would like to go and address. Do you want to talk about the operator's expectation or should I cover that? Absolutely. For us we want to support vendors being have their uniqueness and add their capabilities but in a way that doesn't lock us in. So this is sort of the ideal that we found with OpenStack with its sort of API plug-in model is that we can get to some level of standardization but then allow the vendors to continue to evolve and innovate. But then when it comes to provisioning or service assurance over time, those interfaces are consistent and we don't have to reinvent the integration over and over again. So that's helping us to not be locked in. I'm not an operator however I do speak with many and one key consistent piece of feedback that we get is if you take a collection of VNFs and run them on a platform you've created one level of efficiency for the operator. Now you layer on top of those VNFs VNF specific management systems and orchestration systems so that you have uniquely siloed VNF stacks on top of common infrastructure you basically haven't solved their problem. Maybe you've created some level of efficiency at that very base level in terms of hardware reuse or consolidation. But from an operational point of view you haven't simplified anything and I think that's really the core of what we're talking about here. Yeah exactly trying to find where the levels above the infrastructure start to be common enough to be a service. So sort of in a PAS-like way you're adding more capabilities for orchestration policy control that could be reused across all the VNFs not just one. A really simple example is life cycle management so that the trivial pieces start stop a VM launch it create it destroy it arguably scaling it is another fairly simplistic life cycle management component something that naturally happens in heat already but that's not sufficient to actually operate a VNF. And so one of the things that I like to pick on and Uri has it here on the slide on the left hand side is Etsy and Etsy's architecture diagram for MANO. It doesn't necessarily match it's a nice architecture it's a nice picture the boxes look neat on the on the slide but it doesn't necessarily match directly to the software world that we live in. And so here we are trying to understand where does open stack play in this. Where do we need new orchestration tools that sit on top. And again that's sort of the crux of this discussion. Yeah so Chris has the advantage over you that he knows a slide that is coming so we'll talk about that Etsy stuff what's about the build. So this is the first option and this is not trying to be prescriptive on how you actually create a MANO architecture and specifically I'm trying to not be very specific about some of the sub blocks over here but as a proposal to put something on the table to kick off the kick off the conversation I would like to highlight few aspects of a direction we could go. So we have the Veeam open stack as one example at the bottom and we have OSS, BSS at the top. Not that these are constants that are changing as well but they could anchor our conversation. Then we would see that on the orchestration what we have here is a separation of resource and of service orchestration. And what we find when we look around in the industry is that there is more code, more readiness and probably how you need to talk about resource orchestration and that goes with all of those comments made earlier about the data. We are playing the performance, the predictability, the scalability, the problems of onboarding, the problems of VNF interoperability. So if we start in that area as an industry and for all of the customers who are waiting for this technology there are definitely some benefits one could get. We'll talk about VNFM and specifically some examples available in open stack but I want to highlight an important aspect that you find in that block that is called catalog manager over there. Because that conversation we believe has to start from the information models and from at least one data model. And since this is after all the Tower of Babel and everybody is talking different modeling and there is a reason for that that is not criticism. This is simply because we are coming from different industries that are now trying to share common infrastructure and this is not even telco related. You have compute industry and network industry because of virtualization having to find themselves working on the same infrastructure. We all come with legacies so that situation simply exists and the best way to solve that we think is to start talking about it. And one way to do that is to take something like the Etsy information models and Chris would make his comment soon and then agree on one data model and we'll put that in open source and we would all use that data model as a starting point but we'll have a translator so this is not trying to exclude anything that is happening out there. This is simply trying to focus the conversation and allow us to move forward. Other requirements have to do and we talked about that and in interest of time we'll move a little bit faster there. There was unclear responsibility model. There are open questions especially as telco we need to move from all the resources are in one location to multiple locations. How do we handle that? We don't really have as I mentioned before the model for OpenStack is also a moving target. We don't really have a very clear understanding of what OpenStack supports maybe in this generation but what happens in Mitaka. And then you are trying to have the whole technology being deployable on multiple VIMs and different VIM may have different APIs. So if you look carefully at this model there is some obstruction potentially that could allow you to level the playing field but we all know this cannot be easily done. So can we get to a point that we at least agree on some common denominator of what is expected from each of the VIMs. And here is something specific to OpenStack as well. The notion of group that I mentioned earlier with all of the issues with initial placement scaling, how you deal with AHA, how you deal with failure, all of those issues are work for us to do. For those of you with sharp eyes and those who don't have the projector in their eyes you could suit the difference between this one and the previous slide as that little red line which really talks about two options that we find in the industry right now. One where MANO or NFVO portion of that wants to go directly and interact with a VIM which is supported by the Etsy model and another one where the VNFM takes a larger role. That is an open conversation and we'll see some examples of things happening on OpenStack. Here is the first example. Okay, so you have a list of different policies here at the top with those gray boxes. Different projects in OpenStack have different goals. All of them are suggesting something for applications, something for telco and which one should we pick. Which one can we as a community converge on that is going to provide those services? That's an open question. If we look specifically into it since I was stealing that slide from one of the heat presentations, heat has a concept of a group but not exactly fully mature or didn't have NFV in mind when they did the group as we all know this is coming from cloud formation in AWS or different model. But if we are now looking at one of the information models on the table coming from TOSCA, you may want to look at the next level of detail where there is something called Simple TOSCA then there is NFV TOSCA. And the Simple TOSCA is more about the way you model your infrastructure. Yes, they have compute, they have network, they have storage in there but they don't have NFV. So now they have a new work group, a sub work group actually that is doing NFV. Well, what we have with heat is just the form and not the latter. So some of the aspects we talked about earlier are missing. And I think the rest of the slide should be clear, Tobi. Yes, and then just one thing to add about policy. Policy is very important for TELCOs, setting expectations and then trying to meet those expectations. With this model, the question that is outstanding for us is can you overlay or lay on policy after the fact? Or are we going to have to go back and kind of revisit policy again within all the tools? That is an unresolved question. From OpenStack is coming again from a different angle. Murano started as an, actually started as a deployment tool then evolved into application catalog. At some point there was a talk which to the best of my knowledge is not really there anymore to take it into NFVO, NFV orchestration. Well, as we could see from the diagram, it uses heat, heat has those issues we just mentioned. We have other aspects of VNF friendliness as you could see on the slide that are not necessarily there, but it could be one component of the solution once we address all the other needs. And the last OpenStack example coming up soon. Here we go. Obviously Tech Air, there was a talk earlier today on Tech Air and that I believe is one of the slides that was used in that talk. So Tech Air started as a small project was actually first mentioned in the Vancouver Summit. Summit had very few developers at the time as a little bit more right now and it starts branching out into some of the functionalities that we really need, but obviously it's yet nascent in complete in few areas. However, from the OPNV community when we as an industry looked at the solution that would allow us to coordinate an orchestrator or a VIM like OpenStack with another open source project like Open Daylight, whereas the only place today where you could find standard based service chaining with code that is working on the data plane, there is more work to be done on the control plane. Tech Air was an interesting project to go use in order to connect the two. Mind you, in OpenStack today we don't really have service function chaining with the standard base. There is early work that is going on on a related concept but not identical which is poor chaining. So Tech Air has that but as you could see on the list here as some other challenges. Any comments? I think what you see is a number of different solutions solving some variation of the same problem, each potentially bringing in their own domain specific language and this is experimentation, it's going the opposite from the direction we're actually trying to go which is consolidation and clarity of sort of a single way to do this. And the value of all this experimentation is we're learning but the danger you see is that each one of these projects are really going at solving the problem in a really different way. And I think that's an earlier point about focusing on information and data models and the languages you use to model those, to model is at least a useful starting point. So talking about information model. You think we rehearsed this or something? This is an example, the example on the right by the way is the VNF forwarding graph which actually none of the solutions today support. So that is the idea that from the top I would be able to say here's my network service, it actually comprises of a few VNFs and let me tell you how I expect you to connect them, what are the key performance indicators and so on and so forth. And then you repeat the process inside the VNF which by itself also potentially comprises of multiple elements or multiple VMs. So as Chris pointed out earlier, we have a good starting point with Etsy but it's not exactly like any other standards. It does a very good service for the industry by putting some example but it is not exactly aligned with what happens in open source and then also incomplete as we go. So going back just a comic relief, where do we want to go? And you could see even that little cartoon talks about some translator so I didn't really invent it but it's really about let us have some translation for the information models. So to draw the distinction and basically as you could see on the bottom right of the slide, the work we are involved in in orchestration is tell me what model you have for your infrastructure or for your device and tell me what model you have for the service and let me simply match the two, easier said than done. We talked about the resource versus orchestration and why we think it's probably going to be easier for us to start from the resource orchestration. If you solve these kind of problems, you have made some really good positive, visible, tangible progress that allows us to get closer to the vision of NIV that we all have. And then we could go also into the other part where vendors would seek a little bit more differentiation. So some modest goals would be to make progress along these lines, leave that VNF specific a little bit to decide, start making progress with the information models we have, pick a basic data model that is going to serve as a reference and move forward. But what are the areas you would ask where the information model could, should change? So for your convenience, there are five different areas. The first area is simply finish the work, giving you here two examples of areas where there is a little bit of lack of clarity in the work that is going on today. In Etsy, when we look at different implementation, either open source or proprietary, you see vendors as an example, because the VNFC, which is a component of the VNF and the VDU supposedly are really trying to describe one element, like one VM. Well, there is some duplications in the model, so you want to clear that. Another area that you want to consider is to make sure that you have full support of infrastructure awareness. We were talking about the importance of the data plane, of ability to have SLA in order to drive efficiency to lower the cost, and some of it is there, network awareness is probably not complete. Because we have multiple models, and because it's going to take time for us as an industry to stabilize, we would like the information models to not be too restrictive so that we would be able to have all of those models till we have broader agreement in the industry whether there's going to be more weight on the VNFM, less, what is the meaning of orchestration at MANOR versus orchestration at the VIM, limited to one data center, many, etc. You could see that there is lots of room for vendor differentiation. This is exactly why it's empty over there. It needs to be part of the thinking. As an industry, we only move forward when different communities, vendors get to differentiate, show the industry where there is more value and we move forward. Then we talked about the issues with the information model. The data model is the instantiation of a specific information model that could be programmed again. That's why we need one of those. That's why we think the information model may be the first priority for us to stabilize as an industry. More of us coming together with that is going to help drive us forward and open stack. The second thing that we need to have in mind is that today and you'll see many vendors saying, oh, I have so many VNFs and you could onboard them. The concern would be can I onboard them on any VIM, on any platform? Is it limited to just those VNFs? So we need to have a better industry way to help promote VNF interoperability. Then we need to resolve the architectural issues with MANO and the VIM. I think one thing that doesn't show up on this slide is that there actually are not just the three or so different open stack specifics efforts around MANO that we propose, other is coming from the industry. So it's this wild west and we're really trying to get a place where we come together and understand what are the least common denominator things that we can agree upon. Again, which is why modeling is a good starting point. Because different operators have already gone down portions of these paths for themselves and it's challenging for the entire industry to actually make real progress when you have to make a lot of expensive choices about what are your integration points with the external systems that you're actually going to run on or be orchestrated by. To add to what Chris is saying, I feel like there's some urgency behind what is described here because given their druthers and their past sunk investment, the telcos will continue with their existing OSS, BSS tools and try to open source those things. And I think there is real urgency to make this type of thing happen so we don't, we risk having a lot of fragmentation. Which sounds to me like a perfect segue to this slide. So some action is required as Toby is suggesting and our little contribution to that action is that we actually have posted one proposal for information model with some extensions over what's available right now. We are also proposing that in the session that happens this week in Jersey City, I believe, East Coast and we are really not trying to do anything but to help this conversation move along. So if you have any position, any interest, please help us contribute to that. And last, Chris is at the back of the room with his hands up. So thank you to our sponsor type of slide. Again, those of you who have the passport can get them stamped and we have a few minutes for questions. I had a proposal. Maybe ICAL represents a standard format that we could agree upon between Etsy and OpenStack so that we stop conflicting having our meetings happen at the same time on the opposite sides of the globe. Simple, start simple.