 Excellent. I guess we're ready to start. Good morning, everybody. So, here we're going to talk about the role of NFE research in open source and open standards. I'm Ram K. Krishnam from Dell and here is Pradeep Sen from HP. The other co-authors are busy in other summits, notably HC-NFE, not able to make it. But I hope you enjoy the session. Pradeep? So, we thought we'd, since many of them in the audience may not be familiar with NFE as such, we thought we'd give you a crash course of a few minutes on what is NFE, why NFE, and then get into the open source and resource thing. So, this is just a set of a summary of the kinds of things which a few years ago, a group of operators started looking at network operators, network providers, looking at their networks and trying to see, and looking at trends in their network, usage, traffic, et cetera, and looking at the issues they had to deal with. And to many of you, these may be familiar to some, they may not, but in an operator network, operator's network, everything takes time. It's very inflexible. You cannot change the network very easily. Launching new services is difficult, takes a long time. Even if you decide what a service is and you decide everything about it, all the pieces you need, all the equipment and technology you need, putting it together, testing it, all of that takes time. And pretty often, if you want a new service or a new feature, you have to ask the network equipment vendors who are providing equipment into to develop that feature for you, and that takes some time. So, it's a really long development and service launch process. So, that was the kind of thing people were dealing with, the other thing which was happening back then. So, we started looking at this, I was at Verizon at that time. We started looking at this back in, say, 2007 or so. And traffic was growing rapidly. Now, we all know this is a fact, but we were seeing the trends, exponential growth. And then you looked at the cost of handling that traffic, which was commensurate with the traffic growth. It didn't match the revenue curve, right? The revenues were flat, declining. And here's the exponential cost curve. So, you had to do something. The other set of things which happened, which we looked at were inefficiency in the network. So, you'd have to build the network for peak demand. And most of the time, that part of the network was not being used. So, when you looked at a part of the network and did some measurements and statistics, we could see that 80% of the full capacity over the 24-hour period was not being used. So, that kind of inefficiency in the network complexity, there were every new feature service aspect we were adding on appliances at the edges of the network. So, when we had a new set of services, we were building new infrastructure for that. So, you had a mishmash of networks, of equipment and very complex to handle and manage from an operations perspective. So, all of these were sort of the reason some of us started looking at ways to handle all of these in some unified way. And that was where this whole business of NFV was born. A few of us got together and created a white paper to describe the problem, created this group under Etsy, the NFV ISG, the Industry Specification Group to focus on this problem. And this is just saying, you know, where we started, we were a half a dozen people who talked about this back in maybe late 2011. And then we got a few more together in 2012. And by the time we had our first meeting, we had lots of people joining. And now it's really a very vibrant community with 240 member companies and 37 network operators. And so, what has been done in this effort over the two years and now it's getting on almost two and a half now, I guess. Yeah. So, with a lot of the initial set of framework documents, use cases, requirements were published. And early this year, we had the detailed specification requirements and documents published. They cover all aspects of the architecture. And later on somewhere, we will have a picture, some of you obviously have seen it, but of the overall architecture. And the other thing which is interesting is that a proof of concept program was launched. And you have a large number of proof of concepts worldwide underway with multiple companies joining to demonstrate the concept. So, this is sort of what's been achieved. If you haven't looked at this stuff, you can go to that website. This is the easiest way to go to it. If you just go to Etsy to negotiate, it's very hard. So just go to Etsy.org slash NFV. You'll find all the documents there, other information there. And if you're not familiar with this and you want to start somewhere, I'd suggest look at the use case document and the architecture framework document. That gives you an overview of what kind of use cases are operated, is looking at for this effort. And gives you an idea of the framework they have decided on using. And then this is sort of a visual view of saying what the intent was, moving from specialized equipment, develop for certain functions, to trying to get them into software running on standard hardware. And obviously, you need some things around it. You need orchestration. You need the networking, et cetera. So, where are we now? So, at a very high level, I'd say this is where we are. We are at a point where we're over the barrier of acceptance. Is this even going to work? What is this thing called a virtualizer? Virtualization is totally unfamiliar to most network operators. Why should we even use this? This cloud thing works for enterprise. We cannot use this. So that original set of barriers has largely been overcome. Of course, there's a spread in the market. Some people are still behind. Some people are way ahead. But on an average, you'd say that most people are over the feasibility barrier and now worrying about the operational questions. How do I make this operational? How do I get it into my network? How does it work with my operation support systems? Does it meet my performance? Does it meet my reliability concerns? That kind of a thing. Most suppliers have started to move into delivery of product phase. And all these, there were ecosystems which developed over this time of groups of companies getting together to do stuff. And initially, they were just trying to get things to work together. And now it's more around how do I integrate these into whole solutions. And the standards work, which started with defining what this is about, is starting to get into some of the details. But the other big thing which is more relevant at this forum is that some of us who were working in the standards or pre-standards kind of forums realized that if you just keep following the standards track, the typical telco standards track, the typical network operator standards track, that's a long process. You spend a long time standardizing things, agreeing on things, and then people build products. And that just wasn't tenable in the market today. So some of us got together and said, let's try and see if we can leverage open source to accelerate this. And that's where OPNFV was born late last year. And its intent is to develop based on open source a reference platform where you can test and integrate various things. And more than a reference platform, perhaps a reference framework where you can even try out alternate architectures is what we're striving for. And the goal is really to bypass or short-circuit the standardization process. There's a room for standardization and some of the details will get worked out in the various bodies. But we're hoping that the main part of this can be done through open source. This is the model of OPNFV, that it's not intended to be another parallel development organization. We recognize that a lot of the things in OPNFV we need for NFV are available in some of the other open source projects, like OpenStack, like OpenDaylight, and the others listed here. So the idea is really it's a sort of integration project, so to speak, integration build project where we bring things in from the other upstream organizations and develop the framework. And the idea is as we discover gaps or things we need, those would be upstream back into the other organization. So we are trying to follow an upstream first philosophy. But it's still a new organization, communities building, they're over 40 companies now joined. We'll talk a little more about the projects later. So this is where we are with open source as it relates to NFV. And I'll hand it over to Ram Ketu to tell you a little bit about the research. Excellent. So just to give you a background, so far we talked about it's NFV standards, NFV, and then we talked about OPNFV. So to give you the research perspective on the NFV research group which is formed, so from the early stage what's felt is there is the need for strong research activity, especially the applied research category around the especially addressing the various types of problems we so far talked about. And essentially there is a first white paper talking the fast innovation cycle is one of the key benefits. So then what is felt was research is the right way to make that happen before jumping into products. And also notably the second NFV white paper essentially suggested that we need to create an applied research group on study programs on NFV is basically mandated by the white paper. And also during 2014 the HEC, NFV and SAT together put together research agenda especially which is more near term focus not something way out in the future but kind of ones which are the next ones to the problems to solve so that vendors can productize and operators can capitalize that. That's kind of the thought process there. And then with that with all this happening as you know NFV and SDN are closely related and the SDN research group was the first forum where NFV's address that was created in IRTF the internet research task force which is a parallel organization to IETF which is more standards based. And NFV RG or the NFV research was discussed in SDN RG in IETF 8SX meeting in Orlando. Then this led to further informal discussions you know among various NFV enthusiasts all over the world and also IETF IRTF leadership in IETF 89. And essentially with that the we had the first couple of interim meetings for NFV RG you know and finally the formal charter of the NFV research group was announced by the end of January 2015. That's kind of the quick overview of the story and history behind how NFV research group was formed in IRTF. With that so I will describe you quickly the how the NFV research activities are specifically NFV RG's position. As you can see you know essentially there is one on one side there is open source open stack open delite OP NFV and we have the HC NFV standards basically. And also we have the academic conferences IEEE ICC IEEE group come many premier conferences which often tend to be I mean I don't want to say purely theoretical but tend to be more theoretical solving abstract research problems not the practical ones. And the goal of the NFV IRTF NFV research group is to kind of actually piece all these things together but and focus on the applied research category of problems so that you know there can be a real implementation in open stack open delite OP NFV make a real implementation happen. By that we really mean not writing requirements but actually translating the requirement kind of at least a proof of concept doing system analysis. That's kind of the thought process around this whole research group get something really implemented even if it's fairly straightforward. And right now where we are is it's open participation 300 plus members and there are three meetings formal meetings every year and interim meetings are typically at the IEEE conferences especially the ICC and the globe come but we also have other interim meetings at other locations on demand. And just to give you a quick overview first is we have several work items are debating and then what we said was when it comes to NFV research you've got to really focus again it's near term applied research let's pick a few topics which are of maximal interest to the community and then we said you know the three endless thing found the maximal attraction with talking to several folks operators vendors researchers everybody right and essentially the three work items are the first one is policy based resource management this is around resource optimization open APIs and to give you a business idea of the problems business side of the problems you're trying to solve here is you know reducing CAPEX reducing OPEX and also addressing regulatory requirements such as you know energy efficiency. And the second one is analytics for visibility in orchestration this includes real-time analytics around all subsystems compute storage network energy and also we're looking at introducing machine learning concepts to kind of take these forward to the next level and again this I would say is coming to the category of mainly operational more than CAPEX benefits and also this helps in introducing new business models around analytics and all other ideas. And the last one is service verification of the regards to security and resiliency this is kind of a critical piece especially operationally to make sure whatever you configured is you know behaving correctly and also address security issues that's where this maps and we're hoping to have a direct impact on the open stack telco working group and several other projects which I'll talk about shortly the specific details. So now we talked about it's a NFE OPE NFE and NFE RG so kind of this is a nice you know positioning diagram of how all these fit in and here you have many of you may have seen this picture this is the etsy NFE reference architecture and you know as you can see the initial focus of OPE NFE is around the virtualized infrastructure manager and also the other NFE I components really the NFE infrastructure components and not really the orchestration or OSSPSS whereas the etsy NFE has gone and you know gone into detail and all these aspects and where we see NFE research group playing a role is we talked about work item one policy based resource management we feel that primarily playing a role the WIM the virtual infrastructure manager and orchestrator of course it's not limited to these but the maximum impact will be here. The next work item analytics for visibility orchestration will map to WIM the virtual infrastructure manager and the VNF managers which are managing individual VNF such as firewall load balance or CDNs and the third work item the security and service verification we see the maximum value in the OSSPSS and also the orchestrator. So kind of a nice mapping of how these things are and how the NFE research group work items are. So I want to give you a little more detail on the NFE research group first work item and how this is conceptualized. As you know the first thing to realize is NFE is not cloud and if you take a cloud data center today it's in locations where capacity is not constrained energy is not constrained consider data center or you can you know we're just building it there so that energy is cheap not an issue but now imagine virtualizing a central office in San Francisco or Chicago how it's not it's going to be an expensive value proposition because energy is not cheap because these are the NFE value proposition is around in network data centers and that's where what we feel is there is an opportunity in fact huge opportunity for while we're doing this for operational savings of X and also addressing regulatory requirements that's where energy efficiency is a hot topic as we see and in fact we had a talk plus demo on policy based you know energy efficiency using analytics using OpenStack Congress yesterday. So that's what this work item is and so the related OpenStack projects here are we see OpenStack Heat on orchestration OpenStack Congress which is policy as a service project and we talked about the proof of concept demo yesterday and also there was there's a ongoing project solver scheduler which is around displacement and scheduling we see relevance that too and here is a link to the related NFE research group drafts we have overarching draft on policy how policy needs to be communicated across applications in different layer I mean layers in the infrastructure and also subsystems and also specifically one on the IAAS use case where we actually go down to a system analysis and also other is around service chaining and so now this is kind of a nice mapping of the NFE RG and how it relates to OP NFE we see four projects there the first one is the copper which is the policy project essentially this is around identifying gaps in the virtualized infrastructure deployment policies especially the upstream work which is happening in ODI and OpenStack the other is the promise or the resource manager which is basically resource reservation across all subsystems and the third one is the resource scheduler which is focused on constraint and policy based resource scheduling and the last one is the movie or intent base abstraction layer where it actually takes all these projects and various projects and builds an abstraction layer and as we can see these are more requirement projects but NFE RG the focus is take it to the next level and do a system analysis you know proof of concept and the next work item so here essentially though analytics is it's often talked about common topic I think some of the sticky problems we see especially are around you know simple monitoring techniques you know periodic monitoring which doesn't scale keep polling around CPU utilization or how energy is used or how memory is used but instead we are looking at more of not the whole models the push models basically you know can you make sure that you are pushing statistics only at the times when you need it and the answer is it's not that simple deployment because you need to know what thresholds you need to use you know to push information and these thresholds are very dynamic depending on the type of deployment and that's where we see machine learning coming and adding huge value there we're actually learning the type of workloads which are there dynamically and deciding that these are the thresholds which need to be programmed dynamically so that the right amount of information can be exported to the various layers and infrastructures orchestrator to make the right events happen and a much more scalable way than simple polling kind of give you a detail of ideas we're thinking about so that said we see the biggest impact to when it comes to open stack project around open stack telemetry the C low meter is I think we see a big play that there could be other projects to again this is not exhaustive and we have a related draft and NFE RGNs topic around real time analytics and the when it comes to OP NFE there we go we have a nice project called prediction right which is kind of solving another interesting problem the failure prediction problem but is also quite complex where I think potentially the machine learning concepts could be applied and it works in close cooperation doctor which is more of the failure manager in OP NFE land so the last but not least the security and service verification what we see here is in NFE deployments especially the configuration is going to be very dynamic especially around viral use cases where you're saying that hey there is suddenly an increase in demand and decrease in demand so basically VMs DNFs everything we're going to move around that means there is a rapid configuration change and this introduces a further challenge you know on consistency whether different layers you know from top to bottom are consistent as you expect them to be the way you want it to be when it's configured right that's a challenge we're addressing here and here again when it comes to open stack landscape what I found is very interesting every component has basically something around verification right and I think the key ideas we can bring in or more of how you solve this problem real time and combine kind of the proactive and reactive models because the proactive model this periodic polling doesn't scale very well how do you make it more reactive even based that's kind of the ideas we're thinking in NFE RG to take this forward and we have a related draft around this on service verification NFE RG and mapping to OP NFE we have a PNF FG forwarding graph project where this is talking about service chaining at various layers and NFE architecture and you know service chaining is the heart of NFE and service verification also becomes a key part because you know your the service chain is going to be extremely dynamic especially in the viral conditions viral events and I'll hand it over to Pradeep to close and talk a little bit about OP NFE yes I just Ramky talked about several projects which we could find mapping to the research projects at NFE RG but I just wanted to give you a landscape of one representation of the current set of projects in OP NFE the far left the colors well yes the colors are the blue on the left far left are build and integration projects the little sliver in the middle green are more deployment and testing but the bulk of the projects around requirements and new features and I'm obviously not going to go through all of these projects Ramky talked about a few of them but if you go to the wiki on OP NFE all the projects are described in detail and what I would request is all of you who are interested is just get involved and go look at the wiki get involved in the chats get involved in the online meetings and the IRC channels which are going on there's a lot of activity it's all open it's an open source project you don't have to be a member to join if you're a member all the better so please join and contribute to this and help build the bridge between OP NFE and the upstream projects because we rely on those so if you're active in OpenStack and one of these issues interests you please join and help to make that bridge I wanted to show one other thing you may have seen this earlier in the week the first release from OP NFE is called Arno it's it's going to be out soon people keep asking what the date I'll just say it's weeks not months so but it's it's an initial build of an integration of various things you see on the left so based on OpenStack KVM open daylight OVS so fundamentally it is as you can see an integration of various upstream things and the other piece is that we're trying to make sure that it runs on different kinds of hardware so testing has been going on in three labs around the world and now we're trying to get the common setup available so that we can open it up to everybody but let's just give you a flavor that OP NFE has an interaction with many different open source projects and OpenStack is one of the more important ones but it's not the only one so a lot of issues we deal with are really around integration and how these fit together and how the sort of process models and all of these work together which are perhaps not addressed in the individual open source efforts and I'm going to end with an answer to a question which sometimes keeps coming up well you're trying to use cloud techniques so what's so special just use whatever is being developed for the cloud and that's your NFE and unfortunately in a carrier's network there are many many different aspects which don't map to a typical enterprise environment and here are some examples of things which need more work in research in open source and other areas the price performance issues a big one you have certain functions which really need high performance you just don't get them out of all the current classes and you need special techniques in addition to that you need the ability to select specific hardware not have an undifferentiated pool of hardware all those kinds of things you need much more a much finer grained characterization of the infrastructure for this and you need to expose capabilities from the infrastructure to the software and then the other thing a favorite of mine is that there is a whole wide area network which is the main network of the network operators and when we're virtualizing these functions sitting in data centers whether it's a large data center or spread out all over the network those data centers are participants those functions though they're virtualizing sitting in a data center infrastructure they were participating in the network functions across the network and so you cannot have a silo you cannot just have a simple view of a network it has to be a global view and so a holistic view of SDN techniques and NFE is absolutely required so I just wanted to give you a flavor of at a very high level the kinds of issues of course there's lots of detail behind this there are other issues you haven't put up one of them which we mentioned very interesting the whole idea of a distributed data center which is composed of pieces which are not uniform right I may have a very small footprint a very small set of capabilities here I may have a large set of capabilities here when I put workloads I have to distinguish between those I can't just say okay I'll just load balance and put it anywhere it depends on where that is so we'll end with that and sort of open for questions thank you Pradeep just closing the NFE research group and IRTF is completely open open welcome participation and you know thank you yeah any questions all right thank you can you explain how the NFE research group contributes to OP NFE or to Etsy or to OpenStack oh sure so essentially what we do is a practical example I'll scroll back up a slide in fact so a very practical example what we did was the third link the NFE IA is tracked we have actually gone down and did a system analysis with respect to open stack open-day write in OP NFE so kind of you take this idea here is an idea and then how you actually implemented and which modules it maps to an open stack right not stop at a high level and also the API's and other things that's exactly the thought process as we move ahead with each of the topics we're researching on we talked about certain topics one policy based resource management and all those so go down deeper so that work can happen in open stack or open-day like OP NFE and you contribute that to OP NFE of course yes yes that's what's the question yeah exactly so because OP NFE as Pradeep rightly mentioned is more of an integration project so we're actually looking at the pipeline so basically architecturally how it maps to open stack and open-day light and eventually it will come to OP NFE and that's exactly what we are thinking about the our talk yesterday how we move that work to open a few years and energy efficiency project that those are the kind of ideas we have anyone else you have a few more minutes yeah so so as you can see HC is more of requirements right that's the primary goal but whereas this is actually taking the requirements and also a little more of the advanced ones and you know drilling down right and in fact my co-chair Diego Lopez is a technical chair of Etsy so we exactly are completely coordinated on what we do so that we never overlap you must have explained everything very clearly yeah thank you thank you all thank you