 Thank you very much So thank you very much and good afternoon so here we are six years after the NFE white paper and We've definitely had made some progress in terms of an architecture and code bases But we have to admit that we have very serious problems There's the rate of adoption and the rate of innovation is much slower than anybody who would have thought six years ago and this poses a paradox which is Why is this been so hard? This is a paradox because NFE involves three basic components There's an infrastructure manager that oversees the computational infrastructure There are VNFs That are largely based on existing implementations. So we know how to do these things. These aren't new Then there's a third piece Which is the NFE manager which oversees life cycle for both VNFs and service chains This is new It's not a trivial problem, but it's not a six-year hard problem So what has been so hard for us? And the answer is Integration is the hard problem these individual components these three components by themselves are not that hard But we have connected these components in complicated ways and we've made two fundamental errors First we embedded NFE management in the compute infrastructure and second We made it so that new features often require changes in the pair-wise API So this set of decisions Makes deployment hard because you have to change your infrastructure. It makes onboarding even harder How can you build a VNF that? Integrates smoothly into such an infrastructure and it makes innovation almost impossible Because the three components are now so tightly woven together that it's hard to innovate So how do we fix this? So the answer is to look first at integration solve that problem first before we worry about the components and To solve integration we do it in three steps first as we will describe later We provide a universal integration mechanism, which is a key value store The second is we do not require NFE specific features in the VIM and the third in the most important step Is we knew when to stop that's all we need to do If we do these three things we leave the rest of the design open for innovation the components can evolve Independently deployment barriers are greatly reduced and this creates a lean that is no additional and unnecessary Complication and extensible you can add new features without breaking anything and multi-vendor if you have solved the integration problem then your components can come from different vendors So I'm not going to tell you how this actually works in practice. I'm going to leave this for my colleague. So they were on the saw me Thanks, Scott So I'm going to pick up exactly where Scott left off So Scott talked about we have three basic components and he pointed at integration and in particular Simplifying integration as the problem we should focus on So I'm going to take my time to talk a little bit about the proposal at a pretty high level What our proposal is for how we do this simplification? And to get straight to the point what we're proposing is add one component to this picture And that's a key value store and that key value store is going to act as a single Universal point of integration for all components So before I go ahead. Let me just a quick refresher a key value store is exactly what it sounds like It's a data store that stores keys with their associated values And you have apis to add keys to look up keys to watch for changes to keys There are many open source implementations of these key value systems. They've been widely deployed over the years in production Perhaps the best known the most famous is a system called at CD Which is the key value store that's used in Kubernetes deployed at Google sales force, etc And so with that the natural question why a key value store and the reason is because you know If you cut through all of the apis message syntax protocols and so on The essence of integration is really allowing different components to discover and to exchange state And so in our contacts it state like what is the configuration of the VNF? What resources are available at a node? What is the load on the V switch on server number 15 and so on a Key value store allows us to do this discovery and exchange But importantly it allows us to do it in a manner. That's lean and extensible It's one single mechanism that we're going to reuse for all components and for all state And because the key value store is agnostic to the particular keys and values and components You can change those over time and perhaps more importantly It's lean in the sense that the only thing it specifies is where you go to discover state Everything else in the system is open to innovation so component. That's generating a reading state It can be a VM. It can be a container can be in your vim It can come from vendor a or b the integration doesn't care and hence everything else that integrates doesn't care And that's our proposal really in a nutshell the remaining slides I have a really just expanding on how this integration would work So let me go there. Let me start with the NFV manager In general in the NFV community when we talk about manner We put up these two big boxes NFV orchestrator and VNF manager And this is where you come to do integration What we're proposing instead is let's go a step further and decompose those boxes Based on the concrete functionality that's needed for management Things like placement launching configuration auto scaling monitoring and so on Let's implement these functions as independent entities. We call them microcontrollers And here crucially let's have each microcontroller integrate only with the key value store Independent of all the other microcontrollers You can then start composing automation and management by composing these functions through the key value store So you have a very simple example. Let's say I have the monitoring microcontroller That's recording in the key value store what the load is on a VNF Your scaling microcontroller is reading that value and deciding Accordingly how many instances of each VNF are needed Your launching microcontroller in turn is looking at that value and maybe launching or tearing down VMs Right and this is just one simple example You can imagine extending exactly this pattern to have far more sophisticated control loops And notice I haven't said anything about where you implement any one of these microcontrollers It could be in your VIM could be in your SDN controller could be a standalone micro service All of that works because it doesn't change how you're doing integration And so in a nutshell doing this kind of key value based integration It makes NFV manual lean. So let's say you have a ucpe You don't need probably half of these functions for ucpe device orchestration So you could have a very lightweight orchestrator with the same architecture It's extensible. Let's say that you have specialized hardware in your data center That needs to be taken into account when you do scheduling You can go in and change write your own placement microcontroller The rest of your system stays completely unchanged And perhaps most importantly, it's multi vendor. Each of these microcontrollers could come from a different vendor You could have a marketplace of microcontroller functions We talk a lot about avoiding lock-in on the VNF side It's equally important that we avoid lock-in on the management side and this gets us there So, uh, let me move on now to integration with the VNFs The challenge we see with VNFs the biggest challenge I would say is bridging the gap between where we would like to go as a community in terms of what VNFs should look like We've discussed this at length. They should be disaggregated, stateless, free of an EMS, cloud native containerized microservices so on Those are all great But the reality of what VNFs in production look like today are by and large still VMs that are managed by the vendor's EMS And so what we need is really most importantly A path to incrementally transition from what we have today to where we'd like to go And again a key value store gets us there. So let me start with a very simple VNF. It's a VM It's managed by the vendor's EMS Very simple change we could make is have the EMS Discover what VMs it should manage from the key value store This very simple change opens the door to microcontrollers coming in and doing things like auto scaling healing placement and so on Once it knows what VMs it has to manage we can just have the EMS stock to the VNF the way it always has Let's go a step further the VNF could actually read the configuration from the key value store The minute it does this It doesn't really matter so much whether the configuration comes from the EMS or whether it comes from a different microcontroller And so if it's the right thing to do You can gradually phase out the EMS for that VM And move to a world where these general mano solutions are managing all VNFs You could likewise At the same time be supporting VNFs that are these highly disaggregated components from different vendors That again are coordinating through the key value store in the same way And the point is that you don't have to pick and choose you can have all of these Vendors can choose to put in the resources to evolve as the market proves itself and all of this can coexist And so Take away here again key value based integration allows vendors to evolve in a way that's incremental and independent of each other So the final component and point of integration is the infrastructure manager or the VIM Again in this community There's been a lot of discussion over the years around specializing the VIM for NFV Adding extensions to open stack new plugins to stn controllers and so on The challenge we see with this is one it's slow because VIM code bases are inherently large and complex So it's hard to move them But the second is it leads to a new form of lock-in or what i'm going to call infrastructure lock-in Where you as a carrier you've deployed your NFV solution It's based on open stack and now you think I would like to move to VMware or new tonics or kubernetes It really doesn't matter and you cannot Because your open stack solution had the NFV solution built into it if you take out open stack You're going to break your NFV solution And so that's the situation we want to avoid a recommendation here Do not specialize the VIM do not rely on a specialized VIM Any NFV specific logic should be up in the NFV manager and make use of common APIs That are common across all VIMS So here's one example is that you could go into your infrastructure manager Whether it's open stack or something else and say give me a set of nodes Maybe bare metal on which i'm going to run NFV Go to your stn controller and say connect those nodes and that's all you need to ask them for Everything from that point on can run on this set of subset of nodes So effectively what we've done at this point is made NFV look like just any other workload that's running in your data center Alongside maybe your AI apps, tensorflow, your spark analytics jobs They all look the same from the point of view of the infrastructure The key once you've done this is one of your other apps could be a different NFV workload That's based on a different implementation a different architecture And that is the surest path to enabling innovation and avoiding lock-in The point at which you can run parallel NFV services with completely different architectures and implementations You don't have to worry about being locked into one And so the punch right here again is that key value based integration approach is feasible with existing VIM Layers does not require specialization and doing so allows you to treat NFV as just any other workload And with that let me hand off to Constantine everybody I'm Constantine Polychronopolis with Vmware And I'm going to take it from here for all the five minutes that I have and by the way, I just Locked the complaint with the linux foundation because my friend Arpit refused to twist his tongue and pronounced my last name So You know there is a lot to be said about lin NFV and how it addresses Some of the key challenges we face today and both scott and sylvia Elaborate on those primarily the complexity around onboarding vnfs in existing NFV environments But I want to um and so the argument goes for you know previous generations networks lte for g etc I want to stay For a minute on 5g. It's not here yet at least Not in a pure end-to-end 5g Implementation we have of course The early days of the so-called non standalone 5g which rides on top of lte core But if we really consider The reference architecture of 5g we have a couple of fundamental design principles. One of them is service based architecture Right think about Subscribe notify And how that Fits perfectly with valine NFV design principles How about caps? control and user plane separation And the separation of vnf where the value is for the operator And where innovation really happens for the vendor From the management component which in a big part is there to Assure integration and interoperability Right there is a lot to be said also About the natural fit between cloud native And continuous integration environments in 5g Another aspiration of 5g with the design principles of lene NFV Specifically when we talk about 5g the mind goes to highly distributed network infrastructure, right? All the operators everybody here knows about cold and mech etc And operators have this immense install base Of you know appliance primarily appliance based gear in the central offices the promise of Integrated access and Providing essentially the same services regardless of the access whether it's wireless 5g or Optical or broadband etc So leveraging that footprint that already exists to push the cloud very close to where it's consumed Right a great goal And how again lene NFV can facilitate and accelerate that transition because You have now The opportunity to build all all sorts of cool applications around the kv Store, right and I started thinking about this when scott, you know first called me with sylvia and said, you know Let's brainstorm about this and I thought this is a cool idea, right? Because you can build all sorts of value at capabilities in a kv store things like I started thinking about Continuations and how I can use a call back mechanism to totally decouple Synchronization of the, you know, ordering of applications and vnfs I can request the value if the value is not is not there I will invoke the vnf that is supposed to produce a value Or the set of values and I don't have to worry about, you know fine tuning interoperability between my vnfs Greatly again simplifying Onboarding and allowing the you know the vendors to focus on innovation We are really innovation matters to the operator and to the rest of the community another Very attractive aspect of linear fe is that an kv Store is that it renders itself beautifully to highly distribute infrastructure Where I can have basically a casting mechanism that would allow all of my Exchange information to be localized and therefore create The notion of autonomously operating cloudlets in my environment Right only the information that needs to be propagated up the hierarchy Will be relevant to a centralized, you know controller or orchestrator, etc So again decoupling management orchestration from the value of the vnf And enabling through the kv a distributed kv store To seamlessly migrate workloads Where the uses without having to Resort to complex orchestration Solutions is a is is another Benefit that addresses key design requirements of 5g One of my favorites Is network slicing and again, you know, there is a lot of work to be done Nobody claims that we have solved all the problems, right? What we represent today is a concept that has Strong technical merits and it will involve and require Heavy participation from the community But one of the ideas here as you know The notion of network, you know slicing is again fundamental requirement of 5g where the three You know key pillars of 5g include Very disparate use cases like enhanced mobile broadband And massive machine type communications or ultra reliable High reliability and low latency communications Very different use cases. How do you implement all three of them? That are so different onto the same infrastructure, right? Well networks network slicing comes to the rescue But network slicing requires of course Having multiple overlays on the same physical infrastructure Imagine a case where I can have Enhanced segmentation of the data To each slice through a kv store, right? Part of this, you know Security is one requirement, of course, but segmentation an actual Locality of the data to each slice which may be operated by a different operator different entity Is makes the you know security and privacy around network slicing even more Important And a great solution. So without let me address the last point here, which is Okay, we recognize that there is a significant install base of NFE Question is NFE I How does lean NFE fit into this the answer is we believe that It can coexist In a number of ways in a in a transitional hybrid environment where a kv store Can be part of the Etsy reference architecture We can have A lean NFE Microservices based architecture Co-exist harmoniously with traditional vnfs. There are many ways of doing so one of them for example is to have the open source community Contribute translators that passively integrate existing vnfs into a kv store environment Another way would be to have vnf manufacturers build hooks into the ems's And the vnf management systems that integrate again seamlessly With an akv based store There are many ways here to address the you know interoperability between existing install base and the new world that Is lean NFE focused And happy to address, you know specific questions After the presentation, but let me pass it again to scott Who is going to give the summary of the q objectives here. Thank you Thank you, Constantine. So in my minus two minutes Left, uh, I want to briefly summarize lean NFE technically The main technical points are simple Use a key value store as the universal point of integration And remove the need for specialized vims. That's it But more generally Lean NFE is not a single code base. It is not just one instantiation It is an open architecture an open architecture that is designed to create a lean extensible and multivendor ecosystem for NFV Now we expect many realization of this architecture Some of them purely commercial some of them purely open source and probably most will be a hybrid of the two What are the advantages of this approach? Lean NFE is the minimal design that allows easy integration And leaves everything else open for innovation So the fact that it solves integration means that we can solve the problems of today In a way that's complementary to our current code bases and vnf's The fact that the rest is left open for innovation means that we can solve the problems of tomorrow Things like cloud native 5g and beyond that we are soon going to have to deal with So for those of us who have taken the long and winding road of NFE This is the path to increasing adoption and innovation Now in terms of next steps We hope that you will learn the basics. We have a white paper up on our website. There are hard copies available This is not just something that three of us believe in that gave this presentation This white paper is signed by 10 people who are all industry veterans who know NFE inside and out Some of them come from carriers. Some of them come from vnf vendors Some of them come from other infrastructure providers. They all think this is our way forward Visit our demo in booth 605 Longer term Explore if you want to explore more deeply read the forthcoming technical documents We will be providing some demonstration code So you can see how this works in practice and attend future workshops Or we can talk about both the technical issues and how we can move the ecosystem further And on that note what I on behalf of my co-presenters, I would like to thank you for your attention and ask for your future support