 So good afternoon everyone, I'm going to get started. So my name is Adrian Hoban from Intel. I'm here with my guest speaker today, Alan Kavanaugh from Ericsson. And we're going to talk about software defined infrastructure and what it means in an open stack environment. So to do that, I think let's introduce software defined infrastructure first. Now really what this represents is the start at the low level, start at the storage network and computer sources you've got in your infrastructure. And what we need to do at the first layer of SDI is to be able to offer up a pool set of resources that we can partition. And we need the right level of granularity and abstraction in order to do that. Moving up the SDI stack, this is really where we have to get into orchestration and to look at how we use orchestration as a way to optimally provision between the application requirements and the infrastructure capabilities. Now when you need to do this, you have to look at provisioning based on a whole set of infrastructure attributes, so be it power, performance, where your workload is located, utilization on the server. You have to take all of this into account when you're looking at providing an SDI environment. But what really helps to make this SDI is the application view of the environment. So in this case, we're moving into very much an API defined infrastructure. It's policy provisioned, dynamically automated. And the big picture key here is all of this working successfully is that the application through SLA-related provisioning can be deployed effectively on your infrastructure. So that's quite a move forward from where we're at today with traditional environments. What the result of all of this, of course, is it drives faster innovation. It helps to lower cost as a result of that. So if you can suffer to find your infrastructure, then you have much more flexibility. I'd like to talk about where we're at right now. And there's lots of discussions on this at the summit this week. So when you think about the way applications are developed right now, so they're typically monolithic, vertically integrated appliances, generally deployed with proprietary hardware and software systems. And that's moving to an environment where these can be virtualized. They can be deployed on common infrastructure, deployed across industry standards, high volume servers, and all with the management planes sitting out on the side, helping you to orchestrate and manage and provision all of this. So one of the key things or initiatives happening in the industry comes from Etsy, the European Telecommunication Standards Institute. And within Etsy, there is a specification body working on network function virtualization. So what I want to do with this slide is talk through that sort of end-to-end reference architecture. The chart that I'm showing, it's a bit of a night chart, but it has been derived from the end-to-end reference architecture. It shows the various components that are involved in the telco system. So some of the acronyms might be familiar to me, guys. So let's start at the top with the OSS-BSS. This is where the operation support system and the business support systems come together to be that portal into the telco providers infrastructure. There's a service layer, which is just under that. And the service layer is where these DNS actually get loaded. That's part of how you would add one to the system. On the right-hand side of this picture is NFVO, the top right. So that's a network function virtualization orchestrator. And it forms the top part of that management and orchestration subsystem. And NFVO needs to pull from that service catalog when it wants to try and do things like onboarding and start the instantiation process. Moving down the stack, you see that NFVO talks to Vim on the left-hand side. Or sorry, excuse me, on the right-hand side. That's the virtualized infrastructure manager. I just wanted to call out where OpenStack fits in this picture. And it's mostly in this area. There are some places where you could say it moves up or down a little bit. But OpenStack, you can mostly think of it as being a Vim component. Now as such, if you look at the flow that's happening here, OpenStack is required then to take the request that have come through its API from the NFVO in order to provision the VNF. What that really means is how do you get that VNF deployed in your infrastructure? Now I want to talk through the workflow a little bit because it's important to understand what the responsibility of OpenStack in this VIM environment is and really what it's not responsible for. So if you look at, let's say, if you start with the onboarding and you load up a VNF package into this service catalog, what that really means is you typically have your virtual machine wrapped in some type of container. It could be something like OVF, the open virtualization format, the DMTF standard. With that service catalog entry, you also have a VNF descriptor that could be represented by SIM models or others. You also need to have a network service descriptor. Now the network service descriptor at the catalog level specifies how multiple VNS should come together to deliver an actual service. And they end up referencing the various VMs that you want to deploy. So the NFVO's job is to take a service entry in the catalog, decompose the network service descriptor and the virtual network function descriptor, decompose that into the request that it needs to make to the VIM, so down through an open stack in our environment. So a very first step for onboarding, that's going to be something like a glance image import. You want to get that virtual machine into your environment. Later on, when you want to do the instantiation job, you will have NFVO talking to your VIM and it's going to say, do something like some new neutron commands to create the ports for your virtual network. It's going to get to Nova and do a Nova Boot command. It's going to get, here's the port IDs. And what that delivers then is the VNF actually get landed somewhere in the infrastructure. Lots of things have to come together to make that an effective and accurate decision. But open stacks role is pretty much done at that point from a VNF provisioning perspective. These other components then start to kick in on top of that. So be it an element management system that you would use to control the VNF from the NFV manual layer on the right-hand side, you can have a VNF manager that can come in either direct to the element management systems or into the VNF themselves. And the spec is kind of somewhat open on that. It is also possible for the existing OSS-VSS methods to get into these virtual network functions to go down that traditional path as well. And that's enabled because there's feedback loops going right back through the system. So the higher layer is know where you've deployed your VNF. So all of that together is really what the NFV reference architecture is. So to put that in an SDI context, really SDI is focusing just on this layer of the overall environment. So for SDI, we're talking about a holistic view of the virtual infrastructure manager, the infrastructure itself, be it compute network storage resources and also the connectivity between them, which in this case is represented by this line, but it could also imply things like network controllers. So when we think about applying SDI, NFV and SDN related requirements to OpenStack, we're certainly not in our own in this environment. This is a quick scan of the ecosystem that's involved that shows you the number of open source software packages, standard development organizations that are all actively working on various aspects related to SDN, NFV and SDI. What I want to try and call out here though is that this is not a case that requirements get developed in all these different bodies and they somehow get submitted to OpenStack and somebody does the work and we make some progress that way. What has to happen is that all of these communities need to collaborate quite openly. There are a number of items getting set up. So in OpenStack, there's an NFV working group has been running for almost six months now and there's going to be some meetings later in the week where we're going to get to discuss how these various bodies should work together and how do we be effective in adding the additional requirements to OpenStack that are needed for SDI. Now, I want to move next into sort of given that positioning and we've got all of these requirements being developed, what are the reference solutions start to look like? So on the left-hand side of the picture here we're showing a typical deployment that you might have in maybe a cloud or an enterprise environment. So starting with the server at the bottom and building on that with your host platform be it a Linux solution with some KVA or QEMU in play. V-switch potentially accelerated with DPK which I'll talk more about in a moment. And then your traditional data center type workload apps on top of it. Now these can be managed and provisioned through things like OpenStack or OpenDalight as an open source SDN controller. Where the NFV picture comes in with the Etsy pieces. So we've just talked about a number of these boxes up here on the right-hand side. And you'll see that these guys still very much connect directly to the appliance. But from an OpenStack perspective it is a very similar intersex into this type of a teleco data center deployment. We've got OpenStack and OpenDalight coming in. They have to manage and provision where the VNFs go and how they get set up. That means that there's a lot of commonality that we have to build on. And in fact it's one of the reasons why NFV itself has picked off such momentum because it looks at trying to extract some huge value that has gone into the enterprise space through virtualization technologies and others. And when we look at OpenStack there is a lot of commonality. So really for us at this point it's about trying to figure out what the right extensions we need to make that can work with a more traditional OpenStack view of a thermonelastic cloud deployment. So as an example, the type of requirements that could come in could relate to say performance-related provisioning particularly around determinism of the workload itself. That doesn't mean the determinism of OpenStack. That means the determinism of the VNF. From the perspective of what OpenStack needs to do in order to land it effectively on a platform. There are various items like manageability, responsiveness. So things like alarm generation that may come up through this right-hand side of the picture and how they get back up through an OpenStack environment into OSSVFS. So lots of things really actually interesting challenging problems to solve in this space. But they're not gonna be the focus of this talk. For this talk we're just gonna focus on that STI more of that through the networking layers. So with that, let's have another look at this stack. So if you think about how this is deployed today and you've got various technologies that have some really exciting developments in around OpenStack like network virtualization and overlay technology. And with some advancements happening around service-functioning chaining that really tie into some of that network service descriptor items that talked about for the VNF catalog. So they're all in progress and making some good strides. There are some new requirements that are gonna come in that I think we need to work collaboratively on. The first of those is to start thinking about if these apps become special apps, they become service applications. What will it take to give a service application the right level of, let's say, access, be it at the picture point you wanna plug it in in your network, or the right level of privileges within your environment. A service VM needs to be a different thing from a management perspective than, let's say, a regular tenant VM. A really important topic, and it probably underpins a lot of SDI, and that's unified scheduling. If you think about what we've got in Nova today, there's been some fantastic strides in relation to how the scheduler has been developed. The number of filters that you've got in there, it's been extended quite a bit over subsequent releases. But it's still very much dominated by computer-related resource considerations. From an SDI perspective, we really have to start looking at the holistic view of it. It matters what's happening in your network, it matters what bandwidth you have, it matters how much out quickly that's been utilized, it matters where your storage is. And today, the scheduler we've got isn't gonna consider any of those things. So we have to move forward and work together with the community to look at what is the endpoint we want to get to for the scheduler and then help to pay down the technical debt that has been built up in the community around this, on a path to delivering on this, kind of, I guess, end game of having this unified scheduling of resources. We have to do some work with the applications. From the first, or sorry, with the infrastructure to enable applications to have the visibility into the capability on the platform. So if you go back to that original picture that I showed where you've got the sort of left-hand side of monolithic vertically integrated appliances, they are complete control of the platform. And more than having complete control, they actually have complete access to understand everything that was in that platform. In a typical cloud-type deployment, you don't, you try to hide all of that. So what we've gotta find is the right level of abstraction that allows you to get access to various features such as PCIe device capabilities if you have accelerated in there. You've got particular NICs that you've done some validation with. If you're leveraging features in the chip set or in the CPU. There are certain things that a user in application is gonna want awareness from in an NSV environment. So it's really important that we're providing the right awareness at the API level for those things to take place. Again, it's back to what's driving success in all of this and it comes down to policy. So in this context, policy in SLA, if I look at it on, let's say, the right-hand side here. We're talking here about the networking policy. So it could tie to the group-based policy work which has been making some great extensions in OpenStack. So OpenStack's role up here is to provide an API and a framework that we can properly articulate and describe what that policy and what the network-level SLA needs to be within the platform. Then the requests have to come down to other layers such as OpenDale ID, the SDN controller, where configuration and management happens. And ultimately then, the policy and SLA enforcement happens in the infrastructure and at the server. And that's the real sort of control point that tries to instantiate the application-related request that you want coming in from the top. So if you think about the implication for that, as a, let's say if you look at the networking in particular because this is the SDI discussion. So if you look very much at that networking side, the V-switch becomes one of the critical components in your network. There's an increase in east-west traffic. So folks that would kind of be paying attention to the stats that happen in data centers might say, yes, that's true, but it doesn't necessarily mean that that's within the server. East-west is within a data center. So it could be going out of, let's say, a virtual machine or some other construct in the server, out through your virtual switch and onto the fabric going somewhere else within the data center. That counts as east-west. But if you put it in the context that the core density is growing at quite an impressive rate in the platform, the opportunity for co-locating virtual machines with the right scheduling, a smartness, is actually improving. That does drive a need for that type of traffic to be managed at the V-switch. So that then becomes the policy enforcement point where we need to be able to manage items like your server-level assurance, your access control, and then the performance, of course, is really critical in all of that. So a bit of a segue into one of the capabilities that we look at that can help with performance. It's the Data Plane Developer Kit, our development kit. It's an open-source software, VSD licensed. It's on as dptk.org. And really what dptk offers you is a whole set of libraries and capabilities that you can integrate into part of your Data Plane workload. So for instance, a pole mode driver so you can extract data out of the mix really, really quickly and get it all the way up into user space. There are packet flow classification libraries in there to help you partition up your work, your flows as you see them coming into the system. There's a number of queuing functions to help you with the management of the queues that you might want to come off after you've done that classification. And then there's some buffer management because if you want a really fast workload, then you have to manage how you handle those buffers in your system. The chart on the left is, it really shows the kind of performance improvements we get with a very, I guess the lightweight packet forwarding sample application built on dptk just to show you how quickly you can get packets in and out of the system. The quicker we can do this, the more time is left for the other workloads to actually do what you really want them to do. Now, if you think about what are some of the implications actually to talk about, it's not just libraries here and drivers that you need to leverage. There's also a sort of design paradigm that you typically use if you want to be a dptk enabled app. You would look to do things such as flow pinning. You might want to core CPU pin to a particular core. You have to look at your new malocation. In fact, if you want to get to super fast data rates, at least to lower the cycle count it takes to get the packets up to your workload where you actually want to do the real stuff, then you've got to optimize your platform. And by optimizing for the platform, that gets you the type of performance and determinism that we need in an SDI environment. So what does that mean then? So Numa, for instance, non-uniform memory architecture. So Numa is really all about being aware that the fact that in a multi-socket system, the memory you have can be more closely associated with one socket than the other. So in this case, socket one, this is the local memory first and other memory is the first, the remote memory. So if you've got an application that has been set up to access local memory, that's a much faster, lower latency type of memory access. The same application could, of course, be accessing memory on the remote sockets, which is still fast, but it's just not as quick or as low latency as you can get if you do this configuration properly. So if you can optimize for this kind of platform resource awareness, then driving up your sort of the efficiency by which you use your memory is really powerful and helping to make sure that that BNF application runs effectively. And what we need out of an SDI layer is the configuration, the tuning knob capability in order to be able to set this up. The SDI layer itself, and by extension, OpenStack doesn't need to know about the application or what else has been used. Another interesting point on this too is this isn't just about NFV because any cloud enterprise-style workload can take advantage of this. So if you're assuming it can be co-located on a socket, this is effective. Now, so what has happened in Juneau now is that we've actually put in some work with the community that allows you to co-locate these processes on the same server, on the same socket on the server. So a couple of benefits from it. So I mentioned the memory, but you also happen to get a lot of cash benefits out of doing this, particularly if these processes have to do a lot of inter-process communication or some kind of sharing between them. So the real message here is effectively deploying this makes a lot of sense from many, many workload considerations. And what we need at the API level is that this is sort of exposed up through the API such that we can still embrace the sort of cloud design primitives but can allow workloads to be very tightly coupled to the platform capabilities. There are two other items I'll mention very briefly, it's huge page tables. So, excuse me, with huge page tables, what it means is when you're doing a memory access, there's a part of the memory sub-system called a translation look-aside buffer. Now what a TLB does is it's effectively a cache for memory address translation. So if you're going from let's say, host physical to guest physical, that's normally stored in a page table. Literally it's an entry that you would normally have to access through a memory access. But a TLB would allow you to cache that locally by using huge pages, going from something like 4K bytes up to something like one gigabyte of page table entry size. That allows you to cache much more of memory. So it reduces your TLB miss ratio. That could be the chance of having a TLB miss, which means you don't have to have memory access every time you want to do the address translation. That's a really great performance improvement in a virtual environment. So with that said, let's have a little look at bringing it back in DPDK and how you might associate that with a v-switch and what you actually need out of your STI environment. So from an OpenStack perspective, really all it configures in this environment is this part here on the left. So to put that in more context, in OpenStack for STI, we do not need OpenStack to be a DPDK where are enabled. In fact, OpenStack has no concept of DPDK nor should it ever have it. But what it does need is the ability to connect virtual machines with items like v-switches that have an accelerated with DPDK style primitives. A traditional way of doing it, connecting a VM to your guest down to your whole stream of v-switches, something like VertIO framework, the QEMU style. Which is fine, it's effective, works pretty well, but not very high performing. There are a couple of approaches that really helped improve that. And this is really what we want to push into OpenStack. There are some patches for it now, but we want to work through the Kilo cycle to try and land this in the trunk. So there are two approaches to a thing called user space v-host. From QEMU 2.1 onwards, including 2.1, there is a capability called v-host user. And v-host user is this sort of really efficient path to get your data into the virtual machine. In the dbdk.org releases, there is the similar capability that has been developed called dbdk user space v-host. Confusing names, the same idea in terms of what we want to enable. What we want from OpenStack is to enable the configuration of these other sort of connectivity options. And what that comes down to is this binding types, the virtual interface binding types in Nova, and suitable configuration in the neutron side to help with sort of patching up what a v-switch might need. Because you may not always have, let's say, Ethernet style interfaces that you might want to patch work with. Okay, so that's a key part of what we want to enable for this. Now, if you combine this with a view on, let's say, the Numer related work I just mentioned, the CPU pinning, which would allow you to tie down, not just co-locate workflows on a single socket, but literally tie down your virtual CPU to your physical CPU. So if you will co-locate all of that together, that really helps you to get the maximum performance and efficiency out of your software defined infrastructure. Moving on from these two items, which by the way, on the second one with this v-host user style, one of the great benefits of that is that the virtual machine can go completely unmodified. So it's still accessing the v-switch through a virtual interface in the guest. If you go to the additional step of making your guest dpdk-enabled as well, that's when you can start making use of effectively memory sharing between the guest and the host, all managed in the sort of dpdk v-host style interface path. So if you're looking at the type of performance improvements you can get through v-switches with that, you're going from something in the region of, let's say, at the base point over here on the left, moving to something like 2x-h type of a number for using a standard guest with a dpdk-v-host style interface. And then mileage varies, of course, but depending on how you configure your system and the size of packets, et cetera, you can get all the way up to something close to 10x improvement if you put dpdk in the guest. So that's a variation. You really have to decide what it is that you want from your workload, what the right level of requirements there. And that has to come back again to the policy that we set up, what the service level assurance requests are that you want for that particular workload, the requirements you're going to ask for within the platform so that you can help enable it. And all of this has to get provision in a way that's very much interface-driven. With that, I'll hand over to Alan Kavana. Cool. All right, thanks, Adrian. So my name is Alan Kavana. I'm the guest speaker today from Erison. So, I mean, like Erison is pretty much banging a lot, basically, for OpenStack and NFE, right? So there's a couple of main reasons, actually, why we're actually really here, like to endorse NFE within OpenStack. And why OpenStack is one of the main, like, cloud, ISS management platforms that we've actually endorsed, as opposed to cloud stack and some other ones out there. So I think one of the main things that we really want to focus on is that, you know, when we're packaging a distro, whether it's coming from Ubuntu, Miradis, or Red Hat, we want that distro to be able to service and the application service type on workload. So today, a lot of the services and applications that are actually used in OpenStack for them, what OpenStack is really built for, is what we consider like enterprise endpoint IP applications, right? So you typically have your classic treater web service, and the endpoint delivery basically is a web server or a database, right? Now on NFE, it's a little bit different, right? So it's not to say it cannot be achieved in OpenStack, but some of the little small nuances and configurations and differences, although subtle are very important. And they're very important for a couple of different reasons, right? And the main reason it really boils down to SLA. And I'm actually gonna talk a little bit around that on my next few slides. But the main message that we are trying to do here with partners, you know, like Intel and some other people like Red Hat and Ubuntu, is basically to make sure that we have one OpenStack distribution that can actually fulfill telco and enterprise workloads, jobs, and applications, right? And then we also want to enable like an SDN solution. So we wanna have an SDN solution that's agnostic of the existing network, physical and virtual requirements that the application actually needs. And today in Neutron, we don't actually have that. So I'm gonna talk a little bit about some of the small nuances that you know Neutron doesn't actually address today that we actually really need to have supported basically on the plugin and also on the API layer. So the NFE transformation has already started, right? So I think what we kind of started to see around 2010, 2011 when NFE started to kick off was what you traditionally had, you know, from a vendor like Ericsson, Nokia, Cisco, Juniper, Alcatel, Lucifer, right? When a customer came to Wilson Day basically bought a box, they really bought an appliance. And in SLA the appliance was a piece of software based on a specific hardware build. And the reason why that was done was really for characteristics and determinism. And that's really, really important actually, you know? So what we do is when we ship an actual product and someone actually comes and orders that like from a portal and we actually ship that to them, we guarantee that the application will work exactly as I have said based on the SLA because we have cooked the application and the hardware for that specific build environment, right? So what OpenSAC and NFE have forced vendors like us and traditional Selco vendors is to actually take a couple of steps ahead. So what does the couple of steps ahead really mean? Well, what it means is we no longer basically have an application that's baked on a specific hardware build. So there's no more DSP, ASIC based chip sets. They're not cooked specifically for a given vendor. They're for any vendor out there. And what we really have to be able to do, we have to be able to take the application and make sure we get the exact same SLA, the exact same determinism of performance characteristics as if it was exactly what it was yesterday. So there's a couple of techniques that we actually use then to try and achieve some of those things, right? So what was really virtualization brought about for? Virtualization when it was really brought about by AWS was really so you could oversubscribe services on top of the cloud. So you could oversubscribe CPU, memory, disk.io allocation. In NFE, it's a little bit different. So you probably heard Adrian mention key words like CPU core pinning, new miss scheduling, and they all come back to performance characteristics and having deterministic run times. And a lot of VNF applications actually need that because they require real time characteristics. Unlike when you have your enterprise application workloads where they're stateless, small VMs, small RAM allocation, in NFE, it's the opposite. They are big VMs or big containers are required to run on bare metal. They actually require specific implementation, let's say PCI cards that we actually certify and make sure every NF actually is provisioned on the box and therefore we endorse the SLA. So what we're really doing is we're using OpenStack for two key things. We're taking the application, we're making sure that it can be provisioned and configured on a cloud infrastructure service without actually knowing the physical underlay and we're using the virtualization layer to actually say, well, I don't care if it's a Dell or if it's HP or if it's your own cook stuff or something you actually buy from Ericsson, the virtualization layer will take care of actually hiding and abstracting what the actual CPU and physical infrastructure really is. But there's a couple of little nuances as well with that and we're gonna touch on that as well. So what we really want to be able to do, there's a couple of small little things that I'm missing, right? And you heard Adrian talk about policy and Adrian talked about policy on the network layer but there's also policy on top of OpenStack. So policy really means is that when you actually provision an application that a specific job and the person actually provisioning the job, let's say from a service catalog is allowed to do specific actions or cannot do specific actions. So it could be that you make sure that when you want to provision the application and you actually utilize the SLA that you say it's been certified to run on a specific host operating system, let's say Ubuntu 14.04. And the reason for that is that we want to make sure and go back and say the VNF will actually work and endorse all the SLA characteristics that we would traditionally get when we actually provision that as if it was a dedicated cook box from a vendor but we'll make sure it works on the cloud as long as you can give us some small little guarantees that you'll make sure that it'll actually be provisioned on a specific host with this specific hypervisor with this specific V-switch for example, right? And the reason for that is that the workloads are very different. Persistent, telco, non-persistent, enterprise data workloads, right? So what does provisioning and configuration of a VNF really mean? A lot of people actually think of VNF as a single VM. It's actually not the case. So let's take an example like a BRAS. Most people here are familiar with what a BRAS is. It consists of a couple of line cards that take subscriber traffic in and out from the one basically to the edge. It consists of controlled cards which do the routing and data management. And then it consists of another card for subscriber management. So that typically could be three applications, three VMs or three containers. So what the VNF really is, it's a cluster. It's a cluster of services and applications or cluster of VMs or containers. And typically what most telco vendors actually do is they subscribe how the VNF is actually provisioned on a cloud infrastructure using something called OVF. And that's open virtualization format. And that's a file, think of it as a configuration file, kind of a little bit like Puppet Manifest, but it's standardized for that VNF and for any VNF from any vendor. And then typically what you have then inside, for example, on a service catalog on the PAS is you have another thing called a network service descriptor. So yet again, this is another etsy little terminology. And really what it is that defines how the applications like the line card, like the control card, like the service management, subscriber management cards, are all connected together on the network level. And the reason why that's important is because the catalog basically will take that inside on the PAS and the platform is a service and it will correlate all those things and translate that to API calls. So what we're really saying is that as long as the VNF is actually provisioned to a PAS, the PAS will actually work as long as OpenSec can actually support those specific attributes on the APIs. Ah, but that's where the small problem that we have today in OpenSec. There's a small number of attributes in Novarton and Neutron and Cinderanglans and then a couple of other projects as well that the attributes are not exposed. And the problem with that is then when we want to provision the VNF and deploy a VNF, we can't actually come and specify, can you please make sure that the VNF is actually allocated this specific PCI card with this specific link type. Well, that is a big problem for persistent, performant and deterministic workloads like the telco applications. So if I just take you through a couple of examples as well because security is another big one as well, you know and there has been a couple of discussions this week now that will happen around OpenSec security and the two that I'm really, I would say fond of is really got to do a host attestation. So there is a thing called TPM and it uses a small little key called TXT. And what TXT is actually typically used to do, it's used to certify and validate the firmware and drivers on a specific card. And the reason why that's important for telcos is to make sure that the workloads are run and provisioned in secure environments. Now we didn't have that problem a couple of years ago because when I shipped you a box, all the firmware was tested and certified and validated and you couldn't change it. But in the cloud, we have the opposite problem. The administrator can actually swap out the firmware. He could actually provision a bare metal blade using Ironic. You know, nice little hacker comes on board, start changing some of the firmware that he has access to. The blade basically gets put back into service. Along comes an administrator who wants to provision a telco workload. Yeah, we're gonna have some issues there, right? So the other thing we also want to be able to do is host attestation, right? So you can imagine in glance, you're gonna have like lots and lots and lots of images. And what we really want to be able to do is attest that that specific image has not actually been tampered with. That when the application is provisioned on a specific hypervisor with a specific host operating system, it has been attested and it has not been tampered with in any way. Another key one is VLAN trunking, right? So I think this is like one of the big ones that has been like ongoing. It's like a head wound in neutron for over one year, right? For two cycles, you know, a lot of people have been trying to push this through. And the reason why VLAN trunking is really needed is because in neutron today, there's typically two ways that you actually provision a VM in a network. You order specify the VLAN ID, which is not really applicable because it's really on the provider edge side. Or you let neutron decide what VLAN ID tags it randomly wants to assign from neutron DB. Yeah, that's typically not good for VNX, right? Because what the VNX actually have cooked inside the application is they have their own VLAN IDs. Some they actually use for out of band management. Some they actually use for tagging if it's control traffic. Some they actually use for tagging if it's user plan traffic. So what we really want to be able to do is you want to be able to say to neutron, hey, this is a VNF. Here's the three VMs or containers. Please make sure they're connected over a trunk network. And therefore what neutron will actually do will blindly actually say, I don't care what VLAN ID tagged comes down on the V switch. I'm not gonna swap it out. It's a trunk port. So there are another like massive missing features. Small little features that we really need to make sure that we're exposed basically on the API. So if I go a little bit forward then I talk about what's some of the main missing parts really for NFE, right? So Adrian kind of touched a little bit on scheduling, right? So the main one in scheduling that we have today if you actually look at the Nova filters like weight metric base, they're not good enough. What we really need to be able to do is we actually need to make the scheduler unified. So what that really means is that you don't have, place the VM force based on Nova, but then you figure out, oh, I'm sorry, the network attachment point doesn't actually have like a 20 gig link. Or I'm connected all on the same top of rack switch when I actually need redundant top of rack switches. So what we really want is a unified scheduler across all the common projects in OpenStack between compute, storage and network. So there is one actually up there in Stackforge. It's called the solver scheduler. It's been driven by a couple of people, actually I'm also involved in it. And I would actually encourage people to actually contribute, go and take a look at it and play around with it. And really what it is, it's a constraint based scheduler. And the most important thing with the constraint based scheduler is it's allowing us to actually expose additional attributes that we don't actually have in Nova and Neutron and Cinder today. So if I just go through some of them that's important like local storage. So you can imagine that some specific telco workloads like a transparent cache would actually benefit from actually having an onboard disk locally attached as opposed to having remote central storage, right? So small little feature sets that we'd really like to have instantiated and actually noted and have those attributes basically exposed on the API and make sure that when we actually do job placement and schedule placement for a VNF, as long as we can meet these specific constraints, I can certify my SLA on runtime in a cloud environment. So if I go through one example, so let's say for example I have a VNF and the VNF is a transparent cache. So the first thing you want to be able to do on the API call he says, I want to have local onboard storage. I don't want to take a blade that has no storage, has to have local storage. I also want to be able to have a PCI device type that has a specific capabilities. And I also want to be able to specify and say, hey, this specific transparent cache has been certified on various PCI device from various vendors with these specific drivers. So I want to be able to express all that information so I can endorse my SLA. And the next two are really, really important, right? So if you actually think today, like we have the concept of affinity and anti-affinity and nova, but we do not have that in Cinder and we don't have it in Neutron. And the reason why that's important for Telco is that most things are deployed in pairs or triples or even more. And typically that's for redundancy and high availability. So you can actually see that a lot of the VNFs are actually like they're based on actually having high availability and redundancy on the infrastructure. And we need to be able to expose some of those attributes that we can specify to open so I can say, hey, it's okay to deploy my VNF but please make sure you put me on a box that has a specific CPU type. PCI vendors, here's the ones I support. You decide which one you basically wanna install me on and I basically wanna make sure that I have a host that's connected on two or more top of rack switches as opposed to just all being connected on one top of rack switch. So, I mean, NFE really isn't hard, right? So I think like, you know, some of the things that like we have actually been struggling with when we come through opensack is probably more got to do with culture and more got to do with explaining use cases and requirements that we really have, right? So we're not trying to reinvent new technology in opensack. We're not basically trying to reinvent KVM or ESX, right? All those things are good. Really what we're really saying to people is, hey guys, it boils down to a couple of small points. The first one is API exposure. We can't just consider, you know, it's not just good enough to say, hey, I wanna be able to create a port, assign an IP address in the subnet. I wanna be able to do a little bit more than that. You know, so I wanna actually enrich all the northbound interface APIs in opensack. So the VNF can actually specify and say, hey, I want to basically sit on a blade that has DPDK-enabled V-switch. I wanna be able to sit in a blade that the V-switch will actually support VLAN trunking. I wanna be able to sit on a blade that actually has a non-board SSD drive from vendor X, Y, and Z, et cetera, et cetera. All we're talking about is exposing those attributes through opensack above. Next one is cloud abstraction of requirements, right? So I'm also not saying that the application has to know about the underlay, right? What we are trying to address is that we're allowing opensack to keep the existing cloud abstractions that they actually have, but those abstractions actually need to be exposed up. So in the scheduler, for example, I need to be able to specify some small little constraints from my VNF to actually be provisioned on in a cloud environment. Unified scheduling, right? So I wanna move away from having just a novice scheduler, a neutron scheduler, a synder scheduler. I wanna have one unified scheduler. So there is one project out there actually being proposed called Gantt. It's still a little bit immature, but it has good promise, and also I've been taking a look at the solver scheduler, and I think there's actually good promise as well with that. So the main thing is we want to be able to make sure that where the job has been placed, we don't just force pick the Nova compute host blade and not actually worry about the networking and the storage later. We actually need to make sure that the blade is picked based on compute, network, and storage characteristics and attributes. So why do we really want to do all this? It's pretty simple. We wanna do it because it's SLA-driven placement. That's really what we wanna be able to do. So when you come to a vendor like Ericsson for a VNF, we will say, here's a VNF of BRAS. It's been certified on all these specific platforms, on all these specific PCI device vendors, these specific storage blades, knock yourself out. All we ask is that when you wanna provision the VNF, if you want to get the SLA, you have to make sure that those constraints are met. Okay? So there is a program. I don't know if people are aware of this OP NFV that got kicked off last week. And the reason why I'm mentioning this here, it's really important because it's a multi-vendor industry initiative. It's not an Ericsson initiative. It's not an Intel initiative. It's not a Dell initiative, a HP initiative. It's an industry initiative. It's about taking all the network equipment vendors together and making sure that a VNF can actually be certified on many, many, many different physical and virtual on host, small little product vendors, all part of an ecosystem, on the physical and virtual layers, okay? So I talked a little bit around policy. So policy for me actually starts really on the top. So I wanna be able to have policy and governance from my application at pre and post runtime. That's really, really important, right? So think of it a bit like having business logic in the platform as a service and actually be able to specify some constraints of who gets the provision what and who gets the change what and what specific constraints that actual application gets to actually be installed on. So that's really applicable for enterprise and also for telco workloads. And then we'll have a quick summary and then we do some Q and A. So I mean, like, you know, for me, the most important thing that I really open sac actually needs to actually get behind, you know, that like Ericsson in particular, like myself and some of the guys in my team where we're still pushing is we need to enrich the APIs. I mean, that really is key for service exposure. We need to actually have a lot more attributes and metadata basically expose and endorse on open stack on the Norban interface APIs. Yeah, to add to that, I think we follow up on a lot of Alan's points. We need to make sure that we can have the right tuning knobs in open stack so that we can configure the enhanced properties and capabilities within the server and at the V switch level. Yeah. Like I said, the unified scheduler really, really is important, right? So we need to have a scheduler like on top of all the cross projects. So when we actually do job placement, it shouldn't just be based on the blade. It should be based on the compute blade, the networking requirements and also the storage requirements as well. Yeah, so ultimately to be successful here, it's all about this policy based and SLA based provisioning and placement and enforcement of the application requirements through a comprehensive API framework. Good. So let's take some questions if we have time before we get kicked out. Or we're going to get kicked out. Questions? No, no. Yep, go ahead. You mentioned this data SDK, right? So is it a user space library where pre-compiled application does it need a special compiler? No special compiler needed. It's a user space, primarily user space libraries. Yep. We can chat offline if we're getting kicked out. Okay, good. Let's go.