 is from Sir Khan on NFE. So, Rhino Plus for him please. Thank you. My name is Srikanth Kilaru. A brief introduction about myself. I'm the product manager responsible for Hylian OpenStack to serve the NFE market from HP. I've had the privilege of being associated with this initiative right from the get-go. So, I'm very pleased to introduce to all of you what we are doing with regards to NFE and OpenStack. So, thank you for attending. I hope you're really having a good summit, a very informative summit. I'm glad to see all the interest here. So, without further ado, let me jump into what this is all about, what we are doing with regards to OpenStack and NFE. There are some forward-looking statements. Our legal guys obliged me to have those. So, when I talk about service providers and NFE and in the same sentence when I say OpenStack, when I started out with this project, it was even a little bit unbelievable for me as well because we all know OpenStack is still relatively in its early days. And then, what do carriers need if you take a quick survey? Everyone would say something like five, nine, six, nine. Reliability is the first thing that comes to everyone's minds. That's what carrier grade means. And that's important. That's absolutely important. But we think it's more than that. It goes well beyond that. And especially when you think about NFE, you have to deliver on the availability aspect of a virtualization infrastructure manager, but you also have to deliver on performance. And why is that? Because you're really not deploying just a web server or a SAP server, but you're really deploying VNFs that have very high sensitivity to latency, require high performance, and require low jitter. So, there's a performance aspect of this whole virtualization platform or NFEI that you have to be very careful about when you think about OpenStack environment. Then the third key aspect is manageability. Now, this is something that means many different things for different people. Apart from the traditional definitions of manageability in terms of ease of deployment, ease of use, there's other aspects. How do you upgrade this environment without disrupting your entire service? How do you make sure that this has the OAM functionality that service providers are used to with telco-style interfaces, for example? How do you do fault management and performance management? And then how do you report it upstream? So there's a lot of manageability usability aspects that you have to pay special attention to when you're thinking about an OpenStack environment for NFEI. So, we did actually ask, or I don't think we asked, but we really talked to the heavy-reading guys and looked at what the polling showed with regards to open source usage in a service provider environment. And regardless of the motivations or regardless of where they are coming from, 97% of service providers are serious about using open source. This is no longer a science project. This is no longer a kicking the tires. This is very truly an initiative from the CXO level down to start using open-source-based solutions in the live networks. And this is especially true with regards to OpenStack. Now, I don't think this is so far out there. We have seen other open-source softwares really pick up in terms of adoption, whether it's Linux or whether it's just the pure web services-based area with WordPress PHP. So at HP, we truly believe that open-source has the potential to reach commercial deployment in any one of these spheres and now newly with OpenStack. And this is very important for all of us to keep in mind. That is, what is HP's position in the OpenStack project? And it will become a little bit more apparent as I talk about the product itself. HP is a Platinum member. It is one of the key members of the OpenStack community from a contribution standpoint as well as from a board standpoint, a leading number of developers and PTLs. And we're also, you know, I would like to say we eat our own dog food by deploying it in our public cloud. And we have a dedicated staff of employees well beyond the engineering folks who go into publishing what OpenStack is about and the documentation aspects, the legal aspects as well. So HP has serious commitment from staffing and technology contributions perspective when it comes to OpenStack. And this is going to help us further the cause of NFV in the OpenStack community. So if you look at the foundations of how we build a carrier grade OpenStack product, we start with the upstream OpenStack and then we add a layer of security. We make sure that it is secure. Inherently the upstream open source is not very secure for real world deployments and it's not very easy to deploy from a lifecycle management and configuration perspective. So HP invests in these areas and also we make the indemnification of the open source possible so that you don't run into legal challenges using open source. Now that's good for enterprise. Now we need to go further to make this a platform for NFV. And this is where we take the attitude of how do we take a open source project that has loosely coupled components, each one of them doing a particular service and stitch them together and provide a highly available resilient framework with high performance components and also features that are supposedly available in a Juno or a kilo or a Liberty release but don't really work. How do we fix them? And then help the community absorb them in the upstream. So that is the focus of Helian carrier grade. And I will jump into the details. I know you're all now excited about what this product is, what it can do. One of the key aspects that I should mention here is that and again this will become apparent why this partnership is important as the leading contributor to OpenStack and with our partner Windriver who's a leading provider of carrier grade Linux which is the most widely deployed platform from the network equipment provider perspective. So these two companies have joined forces together to bring together a carrier grade platform for NFV. So looking at what goes into the product. This is a functional architecture, this is not really a software architecture. Built on Intel architecture we have a software stack that comprises of the compute node and the compute nodes are built on carrier grade Linux. This is very important because if you look at the latest spec of carrier grade Linux which is at revision number five, there are a lot of contributors to it. Everyone under the sun that you really care about whether it's Intel or Oracle or Ericsson, Nokia, ALU all of and even service providers themselves have contributed to the definition of the spec. This spec enables you to have a base platform to virtualize your applications so that you have the resiliency, you have the availability and security that is required from a Linux based compute node. On top of that we have a KVM that is enhanced for real-time workloads with real-time enhancements that provide low latency and low jitter. And built upon that is a virtual switch which enables us to give a DPDK enabled virtual switch that gives us the ability to go up to 20 gig of line rate including for small packets by just dedicating two cores per socket. This is the compute node platform and this software is part of the Helian carrier grade distribution. So there's the open stack components on the left and the middleware which forms the, I like to think of it as the glue logic and the monitoring logic that looks at all the different services of open stack that looks at all the services that are running on a compute node and does the fault management, performance management, image and software management as well as reporting to provide a high availability framework. So the middleware plus the open stack core components along with the compute node software forms what is called as the Helian carrier grade. Now on top of this you can run VNFs that are built on any of the standard well-known guest operating systems and they can utilize either standard Linux drivers whether it's a Word.io or whether it is an accelerated virtual nick called AVP which gives you a higher throughput in the VM as well as gives you the ability to do queuing on a pervenic basis. So the enhanced networking capabilities and performance is available for the guest VMs to include just by including a kernel loadable module which is a very simple and quick process that does not include a lot of code compilation or code changes. And the kinds of applications that we are seeing our customers being interested on for this platform is the very standard VNFs, the virtual EPC, virtual CPE as well as some of the non-traditional ones that I would not have expected which is IVR and some of the other voice processes like voice applications like Vulti. So this is what forms the Helian carrier grade architecture. Now peeling the onion a little bit more in terms of the different components I mentioned about the KVM. The KVM layer forms a very important aspect of the compute node and that's because if you do not do any optimizations at the KVM as you can see with the red chart or the chart with the red dots the latency interrupt is all over the map. With the optimizations that we have done in the KVM layer we are able to reduce the latency and also keep them tightly packed towards the lower edge of the graph which means that you have a very consistent and low latency and low jitter. This is very important for applications like IMS, packet gateway, Cloudran, etc. On the data plane the other important element is the virtual switch. It's called the Accelerated Virtual Switch. It is built on Intel DPDK. It provides the ability to do 20 gig of line rate performance at 256 bytes and up and a little less than that at smaller packet sizes. This allows you to be operated using an ML2 mechanism driver in OpenStack Neutron and you can get the benefits of AVS whether you are a standard VNF without any of the AVP functionality that I talked about earlier or the VNF utilizing any DPDK or not irrespective of which you have the ability to plug into AVS using legacy applications or applications that are modified. This is very key. Now, you've heard me talk a lot about virtual switch and some of you may be thinking, well, what about SRIOV? Do you support SRIOV? Absolutely. So we do not have any religion or camp when it comes to SRIOV versus AVS or virtual switch for that matter. We support both. We support the orchestration of SRIOV and we are actually dedicated to furthering the other functionality around SRIOV that is not available in the first release with most distributions. From a switch standpoint, some of the numbers to keep in mind are, like I said, 20 gig of line-rate traffic with two cores. This is very important also, not just from a throughput standpoint but also the efficiency in utilizing the cores. Why is that? If you take a kernel-based OVS, it eats up a lot of cores just to get an amount of bandwidth that you would need to just process a 2 million package per second VM. So in this benchmark example, I have three VMs, each VM requiring 2 million package per second throughput. And with kernel OVS, we find that I have to set aside 20 cores. So that's most of all the cores that are available in a two-socket machine. And after using three VMs each using one core, I'm practically left with nothing. So the efficiency of the virtual switch is very low from a hardware utilization standpoint. With the AVS, we have the ability to get 40 million packets per second just by setting aside four cores and you have 20 cores left to utilize for your VNFs. So your hardware dollars go a long way to run your actual workloads or your VNFs. There's approximately 7x improvement of a VM density per blade or per server. So shifting gears a little bit away from speeds and feeds, which is already important, but I promise that I'll talk about high availability and the management aspects. So starting from making the whole installation process being very easy and simplifying the configuration, we've looked at how do you install the control plane in such a way that there's no single point of failure? And how do you recover really fast if there was a failure in the control plate? So the control node architecture is one of the key areas of enhanced high availability for this product. Also we look at what mechanisms do we have to detect fast failover or fast detection of a hardware or a virtualized element, whether it's a virtual switch or the QMU itself. Similarly, how do you detect and recover VMs that have failed or that are non-responsive? And also how do you do orchestration? So orchestration through heat is somewhat limited when you talk about enhanced platform awareness. This is, again, you will see another area of enhancements in this product. And also the standard OSS and BSS integration that Telco cared about. If you look at the numbers from a detection and failure detection and recovery standpoint, we've been able to achieve 500 milliseconds of failure detection on VMs, whereas with non-modified, standard, distrust of Linux and OpenStack, you see that you have a greater than one-minute failure detection and recovery times. Similarly, for ComputeNode, we're in the sub-second range and ControlNode failure, sub-10-second range, and live migration of DPDK applications is possible. It's actually not possible with most versions out there, as well as failure of network components in the OpenStack architecture is in a sub-second time frame. So these are some of the very important aspects. If you think about how do you enable higher levels of service availability and how do you do things like auto-evacuation on failure or how do you do hardware services without bringing down the entire, you know, VNF service, how do you do upgrades and maintenance of hardware? These are some of the important aspects that we think are important to achieve those ends. From an OpenStack orchestration perspective, heat is the area where we have focused on. The enhancements that we have made in this area are to basically utilize the NOVA scheduler enhancement and the enhanced platform awareness with regards to NUMA node, with regards to ability to use CPU pinning and how do you do auto-scaling in this particular situation by looking at statistics of utilization of network bandwidth or CPU utilization. Some of the other enhancements are, you know, pure bug fixes because we found that heat was pretty buggy again. This is where reality is different from where things are and that's an area where we have, you know, made sure that this is deployable as a product. Silometer is another area of enhancement for performance management aspects. Most of the areas of enhancements were in the network statistics for the virtualization layer, whether it's the virtual switch or whether it's the virtual NIC. Then we made sure that these are available to northbound OSS collectors using telco type interfaces, as well as available through SNMP MIBS and traps and available through REST APIs as well as the Horizon UI. Scheduler enhancements is another key area. We look at the VNF requirements. VNFs require to be pinned to a CPU. They require to be aware of a NUMA node. This is important to guarantee performance and the NOAA scheduler has to be made aware of these when it's scheduling resources. Along with a detailed system inventory, the NOAA scheduler is able to utilize these information combined with the templates and heat to do the proper scheduling of VNF. At the end of the day, while we are making all these investments and changes that enable OpenStack to be production ready, we are making sure that we are doing this in a fashion that enables us to make the changes go back into upstream so that there's no underlocking and we're not trying to create a proprietary version that essentially becomes another VMware. That is not our goal. Our goal is to take OpenStack, make it better, make changes to it that enables you to push back those changes upstream as well as use some high-performance components that are outside the realm of OpenStack, whether it's a carrier-grade Linux or it's a carrier-grade KVM and virtual switch, so bringing the combination of those two components and then having a middleware that's monitoring all these components, creating the times between the performance that's gathered, the fault information that's gathered, and then making intelligent choices about or policy-based choices about evacuation, live migration, et cetera. So this is really the crux of what Helian carrier-grade is about. And again, as I mentioned, it's very important for me to restate this. Thanks to the presence and the leadership of HP in the OpenStack community, I don't see a none of us at HP believe that we'll be hindered in fostering the changes that we are making in this space to enable this version of Helian to be production-ready. We should be able to take it upstream with the help of our community. And what will not be part of OpenStack is, for example, Linux is not part of OpenStack, so we're not saying that we'll push the carrier-grade Linux into OpenStack. It is already part of a category-grade spec. So whatever is part of the OpenStack projects, any changes and enhancements we make there will be pushed upstream. We will also be actively participating in incubating new projects for NFE or Blueprints, as well as collaborating to existing Blueprints, helping them make better, helping them implement as we have done already with other projects and use cases. So with that, I come to the end of my presentation and I hope we have some time for question and answers. There's a question out there. So if you have a question, we have a mic over here, or I can bring the mic over to you if you'd like. So along those lines, I'm very interested in AVS and especially the performance that you showed up there is that an open-source project that you guys are contributing back upstream and if so, into which project would that go? AVS is not an open-source project. However, we are closely monitoring the user space OBS to see where it goes and from a feature functionality, time to market, performance aspects. Great. Any other questions? One of the mic. I appreciated your statement that you were trying to push everything that was appropriate back into OpenStack. Could you be a little more specific on what's proprietary that you plan on keeping? I guess AVS, it sounds like, is something you're keeping, maybe some of that middleware. What's proprietary that's going to stay proprietary? Sure. So in reality, you know, it is about whether it is an OpenStack or not. So the OpenStack projects, No One U-Tron, Keystone, Center Horizon, Glance Swift, Ironic. Any changes that we make are going to go back upstream. Whether it's a AVS, that's not an open-source project. So that's handcrafted to get the most performance out of two cores of CPU. So that is not going to go back upstream as you pointed out. In the middleware, the HA management framework, there's no open-source project for it. Again, we're participants in OpenFV, we're participants in the regular OpenStack community. And as we are noticing, there's no HA framework component built into the OpenStack project. It is maybe being driven through OpenFV, and we will look at, hey, is there an OpenFV framework that's truly open-source, that's ready to be deployed, and that works really great with those numbers that I've shown at which point, you know, we are going to obviously not want to carry the burden of implementing things ourselves, and we want to adopt the open-source components. So essentially what we, where we are, is we are kind of ahead of the market. I've seen some blueprints today in OpenFV, like Doctor, and there's a HA framework. So these are in the early stages. We're going to monitor as well as contribute, right? HP is a founding member of OpenFV, and we don't want to be carrying our private baggage forever. If it makes sense for us to drop it today, we will drop it. Where we notice the industry is that, or the product technology is that it's not ready for primetime deployment. Okay. Oh, sorry. Yes, so the KVM accelerations that you've done are those centered around particular architecture? Are they vanilla generic? Are they things that could be pushed up into the vanilla Linux stream? Or is that not appropriate? I'm not 100% sure on that. I'm not the subject matter expert on KVM, but I believe that we have contributed through the help of our partner Wind River some of the changes to the KVM layer upstream already. I don't know the latest snapshot of where it is, you know, have 100% of the changes gone upstream or not. I don't know that yet. So you mentioned that the VNF fault detection is about 500 milliseconds. I still think it is too big, too long. What causes that? And if we end up with 500 milliseconds, this will break down, period. Right. So again, this is the starting point for us. This is the V1 starting point for us. And some of the numbers that I'm told by our architecture team, they come from the fact of, you know, how many end points you want to monitor and what kind of a database structure you have in the back end and how big is your control node footprint? Are you willing to have a much larger cluster of control plane nodes if you want to, you know, reduce the granularity of the monitoring? So there's a lot of these design considerations. And, you know, as all product management rules say, what is your V1 requirements? You know, what is the best tradeoff without making the project be, you know, a project that takes too long and costs a lot? Those are some of the considerations we have at this point. In the carrier grade, you know, reliability means really F caps management and you are bringing all of that stuff into open stack management. It's a really great thing to do. And there is a great demand for that. In fact, we have been receiving a lot of requests in terms of how to provide that carrier grade reliability performance security management and configuration management also. So one of the things I was wondering is that itself looks like a management open, you know, source type of platform. Are you considering that as a special thing that you could start or whatever? So again, you know, I think this is an area that's ripe for innovation. OP NFE seems to have some promise there. In fact, I don't, I'm blanking out here, but we were talking about a way of having a modular plugin-based architecture where you can insert vendor-based F caps industry, sorry, commercial solutions instead of open-source solutions because open-source solutions may not be ready, may not be scalable. So again, these are some of the mechanisms that the community has to look at as a whole. And we will foster that dialogue. We will foster that work to the extent possible as HP, but I think the whole community needs to think about this. What about F caps in OpenStack? And how do we make it go beyond open-source, right? Nice, Shrikanth. Do you have integration touchpoints with, is it HP OneView by any chance? Do you have any touchpoints on how you integrate if not monitor some of the elements in there? That's a great question, actually. That's what I had in mind when I was answering the gentleman. And this is where we need to go, right? If you look at vendors like HP who also have another line of business in selling hardware, you know, they spend a lot of investment making OneView and such software that does element management, fault management, et cetera, why not have the ability to use them to better the whole solution, right? It could be a Dell's management software, it could be Cisco's, UCS Manager, so on and so forth. So whether it's networking layer, storage layer, or server layer, each one of them has its own F caps management software in regard to be able to figure out having that as a pluggable software to make the entire solution better. And some customers may say, no, thank you, we'll go with an open-source-based software. That should be a possibility either. Great, so where can people find you if they have more questions? Okay, thank you. I'm at shrikant.kilorealhp.com and I'll be somewhere around as well if you can grab me. All right, thank you so much. Another round of applause, please. Thank you.