 Okay, so welcome to the NFE Bake Off, so this is probably the first time we've had so many people from the NFE community, vendors in the same room together, so it's pretty exciting. So this would be a great opportunity for you to really get a good sense of where the community is heading, and for the people who were at the previous panel on the telecom roadmap, I think it'll be quite enlightening, so unfortunately we only have 40 minutes, so we're going to get going because I think we have a lot to cover, so I'm going to get started with some introductions, and the first question I'm going to ask is, who are you, and what is your company doing with NFE to get started? My name is Shrida Ramaswamy, I'm a principal engineer in Brocade. Brocade is a software networking view. Our company, as you might know, has a lot of different products in the NFE space, including an SDN controller, which is a commercial version of an ODEAL Open Daylight controller, and we have a lot of different VNFs that we currently support, like virtual routers to virtual EPC, VADX, and there are many others that we support today. In general, our company Brocade operates in the space of NFE in what's called the new IP, so we are very much in the space trying to yield this transition towards NFE from the old way of operating things into the new way. Hi, my name is Shrida Grawal, I am a product manager at Juniper Networks. I'm basically responsible for their virtual firewall product, so again, in context of NFE that would be one of the key VNFs that a lot of customers are looking for to deploy. And also, I manage some of their mid-range physical firewall platforms. With reference to Juniper's involvement with NFE, I mean, we were engaged very early on right from early 2013. We are actually kind of on the forefront, evangelizing where NFE and Etsy architecture is going, and again, we have a lot of investment in terms of engineering and architecture. Working with a lot of tier one and tier two service providers, really pushing different use cases with SDN and NFE. In terms of solution, again, broadly, we have kind of the NFEI components with our career grade switches, routers and firewalls. We have an SDN controller with contrail, and then we have essentially VNFs, so we have virtual SRX, which is our virtual firewall, and virtual MX, which is our virtual router, and we have a bunch of other VNFs in the pipeline. And finally, we have a complete manual solution as well with our contrail cloud platform. So again, we have the complete end-to-end solution, which is very open for our customers to really transition and move to NFE. I'm Bob Hattleton. I'm a cloud NFE software architect with Alcatel Wusent. I'm in the Cloud Innovation Center, where we work with all of the Alcatel Wusent portfolio products as well as third-party products and ecosystem vendors to deploy all sorts of applications in a cloud NFE SDN environment. Alcatel Wusent has a whole portfolio of EPC, IMS, OSS products, basically everything in the telco portfolio, as well as specific NFE SDN products like Nuage and CloudBand, and at this point, basically the whole portfolio has been refocused on NFE, and that's definitely the direction going forward. Hi, my name is Sudhir Ketamukka. I lead a product development team, primarily responsible for the net management and orchestration for the network functions in Ericsson. But having in that role gives me an opportunity to look at both Ericsson's own network functions and the roadmap, as well as integrating with various other vendors solutions. In addition to, I mean, I think, I don't know how we can give unique answers here about, you know, what our companies are doing, but you know, one thing I wanted to add is also a pretty big player in the systems integration space, working with some of the, you know, tier one customers at this point, but when it comes to the applications, yes, virtual router, virtual EPC, virtual IMS, they are, you know, pretty in a very good state with NFE, and all other suite is also towards the NFE direction at Ericsson. Hi, good afternoon. My name is Tarek Khan with HP's NFE business unit, and I think this is a group. Thank you, Beth, for organizing this and having this discussion. So my role within HP is to try to figure out how we can use cloud and network virtualization technologies and apply it to NFE. So kind of the, some of the discussions that are happening over here. And let me see if I can try to give a unique answer, where we know at HP what we are not doing. So we are actually not in the VNF business. We do have some VNFs, but that's where we feel the network functions, the innovation, that's where it's going to happen. And with the larger equipment providers and also smaller ISVs who are coming in. What we are focusing on is the platform. And the platform essentially goes from NFEI, both physical and virtual infrastructure, the virtual infrastructure manager, OpenStack being providing part of it, and the management and orchestration. So those are the areas that we are focusing on so that folks like Verizon and other operators can just focus on looking at what VNFs to bring in to the platform and be able to run it in their networks. Thank you, Tarek. I'm Prakash from Huawei, and I represent the R&D in the, what you call, the standards. And mainly, if I give you a one-liner for Huawei, we are a full solution provider for NFEI. So we do end-to-end everything. And of course, the biggest strength is 75% of the carriers in the world are our customers and they bring most of our revenue. So our revenue model is based on being open, and that's why we are one of the, what do you call, the members of the OpenFP, Open Platform for NFEI. Our participation in ITC is never questioned because we have been in almost every name you can think of NFEI, whether it's MAC, whether it is related to optical. So we have a wide range of product line. Currently, for NFEI, what we are doing is Open Platform so that we can establish the standards which will help us bring our product line, which are already there, but to make it interoperable. That is the main focus for us. And interoperability is the only word I would like to use here. Thanks. That's a great intro to my next question, which is by the way not in order. Just throwing you some curves here. So how does your NFEI products, and so obviously you all of you have some NFEI product in some form, incorporate OpenStack? And how does your company contribute to the overall community efforts? Just I think relevant to this conference in this community. So we'll start with that. Okay. Okay. So the OpenStack is the de facto virtual infrastructure manager for Ericsson, any solution that we provide. So we are adapting OpenStack, both for our internal IT as well as the network functions. From a contribution perspective, we have made contributions specifically in Nova Neutron and Cylometer areas. And these days it has been more in the OP NFEI. It's not a direct contribution, but what we are trying to do is stabilize those requirements for the NFEI and push that towards the OpenStack. And we partner with various OpenStack vendors across the industry. So yeah, OpenStack has been our cloud store, has been part of our cloud story for almost three years, three and a half years now. So Brocade really believes in enabling almost all their products orchestrateable through OpenStack. So we have the switching lines and rotors, the switches like the VDX and MLX and ICX, they are, you can orchestrate through Neutron. So we have Neutron plugins, something that we brought in. We also have all for our virtual assets, the virtual VNFs that we have. We basically have plugins enabled through Neutron. So we made sure all of our products are orchestratable through OpenStack. So that's something we made sure, this is an interesting and an important ecosystem for Brocade. And it needs to be, all of our products needs to be enabled. And beyond that, again, our HDN controller is something that's validated with Neutron. We strongly believe the Neutron, for the success of Neutron, and it would definitely enable Brocade products to be consumed through Neutron APIs. And beyond Neutron, we are making significant contribution in our involvement in the Tacker project, which is the HCMano OpenStack project that's gaining really big momentum in the last few cycles. So again, I'm leading the project, but we are actually really contributing to the project as well. So that's... Yeah, so again, from Juniper's perspective, we have Contrail, which actually interacts with OpenStack via the standard Neutron plugins. We have Contrail Cloud, where we have essentially a cloud management platform where we have Juniper's OpenStack, destroy as part of it, and we have made contributions to Neutron. From a VNF perspective, we have Virtual SRX. Again, we have plugins, Firewall as a Service plugin for OpenStack for that. And there was a talk this morning where we shared some ideas around how we can enable to provide very similar capabilities that customers have on Firewalls in a physical environment with OpenStack. So scheduling policies and doing logging and things like that. So again, we expect going forward, we'll be making a lot more contributions in the Firewall as a Service plugin, plug-inside. And I guess some of you might know that with Contrail, we have actually open sourced it. So we have open source, open Contrail, which again, we are trying to drive that option of SDN controllers. We have that open Contrail piece that we have. At Akuta Usent, OpenStack has pretty much become the de facto platform as with everyone else up here. And our cloud band node, cloud band management system are both built on top of OpenStack. NewAge works very close with OpenStack. All of our portfolio products are designed at this point to run on top of OpenStack. And in terms of contributions, in the last probably six months, we've really ramped up contributions to areas like Heat. Mistral is another project that we're contributing heavily to the Tacker project as well. And I believe if I'm not mistaken, we just recently started a new project that we're starting with a community for root cause analysis. And I'm going to mess up the name, but I think it's Vitraj. Thank you. And so I think it took us probably a little while to get started, as with any large company getting through the wires and figuring out all the different IP issues took some time. But I think at this point, we're really committed to OpenStack. Tar. Thank you. With HP, like I said, we focus on the platform and OpenStack absolutely is the platform. So we have a couple of different flavors, distributions of OpenStack. So for NFVs, specifically, we have a distribution of OpenStack that's just meant for network workloads, helium carrier grade. Within the OpenStack distribution, our, I believe for the last three or four releases, HP has been either number one or number two and number of commits, number of reviews. So we have been kind of integrated OpenStack in our DNA, changed all our cloud solutions to be to be powered by OpenStack, both private managed cloud and so on and so forth. And then around OpenStack, we have a number of solutions, SDN controllers, our NFV, our all the components basically work. Besides upstream contributions, we're making sure all our products are validated with OpenStack. Okay, so what we have, we have two philosophies. One is bottom up, another is top down. The pain point is in the top down, not bound areas. OSS, BSS carriers are really affected by that. So we are doing that through the TOSCA and various modeling and all that. So that service modeling aspect of it to bring down on the product. Bottom up, of course, OpenStack is the king. There is no question, Wim Leven and SDN is another part of it where we are participating both in ONOS and the ODL, ODL for Enterprise, ONOS for the carrier grade. And our product lines all are mapping so that we are able to do in an open manners. We work with Ericsson, we work with Brocade, we work with Cisco, every one of them, we are participating in the open platform for NFV so that we can bring all these together as a company which is having such a workforce and such a large 200 plus people of us are participating in open platform for NFV. And OpenStack is the major upstream for us. So you go back from six to seven, Diablo onwards up to Liberty. We have got at least one module to focus every time. So we started with NOAA, we have done with heat, we have done with neutrons, cilometer and currently we are of course bringing edge computing so we are participating everywhere. We want people who are good at leading to lead and we help them, not that we cannot lead, but we want to make sure we fill in the gaps especially like in open NFV we have focused on testing so that products can be certified, tested and can be released to the customer for usage in the green field as well as in brown field. So thank you. So I don't know how many of you saw the previous panel but this relates to it. So the telcos, me as a customer obviously, we are interested in NFV but as far as I know none of us have actually deployed it in production. So what do you see as the challenges as to why NFV has not been widely adopted in the industry today? So what is that? Akash? Yeah, sure. We are seeing the challenge coming. So when we started with NFV, at CNFV we said that okay, CAPEX, it disappeared, OPEX, it disappeared. So right now it is the how do we enable the value chain so that the carrier really gain out of it. So the challenge has been that we say something and then it hurts us the very next time. So when we say, oh, we will reduce the CAPEX, did it really? No. Yes, it did to a certain extent, but it is not the solution. OPEX, yes it did reduce maybe 15, 16 percent. Now the new services that can be brought in, that is the key. So even if we start with a POC, okay, POCs end in POC, they really bring people together. That's fine, but at the end of the day you need a carrier grade, mission critical platform plus the VNFs, whether it is a VEPC or whether it is a VIMS, whether it is for the mobile or even for fixed network. So that's the challenge we are facing and getting the standards and the de facto standards like OpenStack converge is the most difficult part. We are, that's a challenge and that's, we are trying to address to see that both of them move closer to each other so that the industry can adopt based on platforms that are there from like fusions we are from. Yeah, talk. I think like the last panel was talking about the issues are threefold. They are organizational issues to be able to introduce this virtualization. The organization, especially the large telcos, they have to change their organization. Most of them are in the path of it. Some of them have implemented it which absolutely is going to help, but now the structure is being put in place. They are technological challenges. There are some very specific technology obstacles need to be addressed to be able to not just virtualize because NFP is not just about virtualization. It's the orchestration and automation that goes along with it as well. So some of those gaps that we are trying to be able to address. And the third one is just the operationalization or the support, new support structures that need to be put in place. There's no certification or standard body that's defining what SLA now that operators are going to be running their platforms with functions coming from different providers to be able to figure out for the function provider to sign up for a five nines SLA, what does operator need to be able to provide to the function provider so that the operator becomes a provider to the function provider. So some of these things, operational issues, technology and organizational barriers are putting through. But right now if you look, there's a lot of progress. And I think a number of operators, what we are seeing is at the cusp of going into field trials or maybe into production. Yeah, I agree with Tarik and Prakash I said. And in addition to that, I mean, I come from like OSSPSS side of the business and operations like Tarik mentioned is a huge thing. I think we still have maturity that is required in the NFVI and the VIM layer support for the service assurance and the F CAHPS side. And one of the examples is yesterday or the day before during the keynote, we saw the statistics about adaptation of various projects in OpenStike. We see Cillometer has been one of them, one of the early projects, but the adaptation is pretty low. And when it comes to telcos, these kind of things are extremely important and they are the last ones to be looked at by any community. So there is some maturity required there. And from from Mano's standpoint, which is another area of interest for me, operators are mixing and matching things here. I mean, for good reason, obviously, I think that's one of the benefits of the whole... I think we have one of everything. Yeah, so exactly. And the standards are not matured, which means we test with our own systems before you go out. And when you try to integrate with other things, there are issues. And these are challenges. They are not complaints, but that slows down the process a little bit. So I think in reality, these are the challenges that everybody has to face. And I think we made a good headway in the past year or so. Hopefully, things get more standardized in the future. I definitely think standardization is a huge issue. We don't have Bellcore setting standards for us anymore, which is a huge challenge for the providers. I think one of the other major issues is interoperability with existing systems. So telcos have a huge amount of embedded OSS systems, embedded BSS systems. They're not simply going to rip all these systems out. So that means we have to be able to talk to SNMP. We have to be able to talk to Corba. We have to talk to all these technologies that probably were defined before many of us in the room were born. But that's simple fact of life. Telcos are not going to start from Greenfield. And so when you combine that with the need to do things like service orchestration, which does not have defined interfaces yet, does not have defined specifications, it's really kind of demonstrates how early we are in the process. Things are moving very quickly. And I think one of OpenStacks' strengths is also one of the challenges, because there's more than one way to do it. No matter what you're trying to do, there's more than one way to do it. And you have to decide, do I want to use heat? Do I want to use tack or do I want to use NOVA directly? Do I want to use containers? And as an architect, I have to go through and make all those decisions for every single project. And it's a huge challenge. Sometimes it's easier to have a small tool set and have more restrictions. But that's not what we have. We have many, many, many choices and that's one of the challenges. Yeah. So again, I think I agree with others. I mean interoperability and really carrier grade solutions that service providers look for, I think that is, that is maturing. And I think we'll see more adoption of NFE. I mean, firstly, on Juniper's side, we are engaged with the whole XCP, virtual CP. We are seeing a lot of interest and we expect some early deployments hopefully this year. Just talking about VNF, that's kind of my focus area. As customers are looking to kind of replace their existing physical firewalls to virtual firewalls, I think there is some more work that needs to happen to bring the same level of performance and functionality in the NFE environment. So for example, today virtual firewalls cannot get to that level of performance. So I think as an industry, we need to evolve to more of a scale up, like how do we get more from a single virtual solution as well as how can we scale out. So with an open stack, things like auto scaling and all needs to improve so we can distribute the load. I think many good points have been covered. So from a challenge point of I don't see this as a challenge. I think we are a lot of things work in progress. I think a lot of ground has been covered, particularly on the compute side. I think we have spent a lot of effort in bringing the feature set that's sort of career grade, if I may use the term. But we got to finish the job. I think we have a lot of effort went into NOVA in making the VNFs to be performed as well it's supposed to, so that it can match the performance of a physical. But we got to finish the job. I guess that's where we got to focus. I mean that's what I see as a challenge. And there is more work to be done in the orchestration. I guess again we have taken initial steps. I think we got to finish the job that we have started that things are in flight. I see more that as in progress than a challenge at this point. Thank you. So here's another one. I think we all agreed and again we mentioned this at the previous panel. There's some gaping obvious holes in the stack when it comes to being an NFE platform. So what do you see as the missing capabilities and what are you doing about it? So maybe touch base on the thing that I mentioned. So one thing again in the last three cycles I can see we have spent a lot of effort in bringing the NFEI aspects of the stack up to career grade. That amazing amount of work that went into Nova particularly. So what I see that's missing is as we go up the chain, it's not just landing the VNF, it's the orchestration piece that's quietly missing. So if you go see how the Nova compute is supposed to be geared for an optimal placement, there are like n number of knobs, you need to place it correctly before it would perform the way it would. So we cannot expect like every operator to go learn those n number of knobs. So that's where I think there's a role for an orchestrator to basically simplify these things. We sort of need an easy button for all these amazing features that folks in Nova and Neutron for things like SRV have done. But now is the time to make those features easy to consume for the operators. And that's where the role for an orchestrator. I believe we are taking an initial stab using the attacker project again using a standard templates. But I guess that's one of the significant gaps that we need to plug. Attacker seems a little immature, undefined. It's getting there. I guess this is something we are iterating really heavily these days. And in fact, we have a lot of interesting sessions that went. We have a lot of ground to cover, but I think we had a very good start with the project. Yes, I think, as you said, I think a lot of work has been done on an FBI side, but I think we need to move up and all of the other interfaces that we have defined, we need to start looking at a standard standardization and the standard protocols. So all of these service providers who are basically looking for an open environment where they can plug and play, it becomes easier to mix and match different VNFs, OSS, and VSS solutions. So that's one. Also, again, on the firewall side, I think we need to look at how OpenStack can easily plug and play with different kind of virtual network functions and the ease of how we can do deep packet inspections. All of that work needs to happen. Security too. Security is a key piece of customers moving to NFE. I think a lot of work can be done there to enable our customers to be more secure in these environments. There was a comment made at the last session about what can the telcos do to contribute back, and I think one of the things that the telcos can do is really help with standardization of interfaces, standardize how you want these things to talk to each other, how you want to handle alarms, how you want to handle measurements. The fact is OpenStack has a lot of overlap between projects today. We have an application catalog in TACR. We have an application catalog in Mirano. There's things that Solometer can do that Manasca can also do. There's things that Heat can do that Sanglin can also do. Those overlaps really need to be kind of resolved, or at a minimum, there needs to be some coalescence around one, I don't want to say one way to do it, but a set of requirements and required interfaces that we can start solving these problems using these different tools and understanding what the telcos actually want. I'll just give an example of two specific areas that I can think of. One from an operational point of view, like I mentioned before, resource management, resource reservations, et cetera. This is being driven through again OPA NFE, like I mentioned before. Hopefully, we will have solid requirements there and that will translate into the WIM NFEI as well. And operationally, Doctor is another project that Ericsson is pushing in the OPA NFE. And when it comes to the gaps, we talked about it, but the neutron support for various things like Layer 3 and MPLS, et cetera. From a contribution point of view, Ericsson is engaged in the gluon along with a few other vendors and operators as well. So the BGP VPN project is something that we are very much interested in and contributing towards. I think I'll kind of talk and maybe Bob going slightly the other way. So there's, of course, everyone says that NFE is introducing a big change. And one of the changes NFE is introducing is that it's making telcos move away from interfaces that are predefined, where people on the either side write solutions to it, to moving into an API-driven ecosystem. And what I would argue is that overlap between projects, overlap between different things is a good thing because that means the innovation is happening at different places and you're not just constrained by one thing. So I like what Tacker is trying to do, absolutely greatest thing. Talking about promise, talking about doctor, there's other ways of doing these things. I think what we basically need to be able to focus on is there's the steady state production environment that operators need. And that cannot be, you cannot be looking at the shiny new things that keep on coming out, which may be six months, a year down the line. Is that we need to make sure that the production, carrier grade production quality solution, which essentially comes down to, essentially the deafcore project, those are rock solid. There are some capabilities that are required, like EPA enhanced platform awareness is required to be able to get most out of the system. So there's some more work needed in NOVA and Neutron to get those things. I mean, I agree that resource reservation or a little bit better resource scheduler is required. OpenStack has already taken some steps towards taking scheduler outside of NOVA, the sole scheduler solver, some work over there so that this scheduler is able to schedule based on the VNF descriptors, the network service descriptors that have been defined by the VNF providers. Operators choose how they're going to deploy and once these core capabilities are there, then we feel that you'll really be able to operationalize and let the abstraction work the way it's supposed to. So from WHOA's perspective, we have been trying to solve issues and what we have done is one of the main things we took up is from service provider point of view, service bundling, service chaining, those are important for offering the service. So we have embedded ourselves into Neutron, we have got the port chain, the service chaining, which is one of the key pieces and over and above it we are trying to do the modeling, like modeling of network. So simple thing is, is computing the network or is network the computing? So Scott McNally, you remember the good old days, he says, network is computing and so that's the key and so SDN, without SDN you cannot do anything even though we have NFV but the glue pieces which can glue everything together is the SDN with open flow, without open flow. It's a question of software defined networking. How we want to do it? Netconf you use, you use Yang model, you use whatever TOSCA, but all thing is modeling it the physical, modeling it the logical, bringing together all these pieces, use all that is available in OpenStack, whether it's NOAA, Neutron, Cinder, Cilometer, whatever it takes to get the F caps that our people describe here, that's the key. So we are trying to solve the problem and that's the key message I would like you to carry. Any carrier they know that it's not going to happen overnight, but we should be persistent in resolving the issues that are pain points for them. That's the key message from us. Thank you. We have about 10 minutes left so what I'd like to do is open it up to questions and I've been asked to have everybody stand in front of the microphone otherwise you don't get recorded for posterity. There's a microphone in the middle. Hi, I have two questions. One, can you please talk about your current adoption or what is the trend that you're seeing in the next six months? Second thing is it goes with the deficiency or lack of capabilities with OpenStack. The HA is traditionally a problem and something that OpenStack is working towards it, but with this career grade 59 requirements, how do you manage that or how do you bring up 59 availability given the constraints of HA with an OpenStack? Thank you. I can take it up. We are having a project called Multisite and we also have been working with Ericsson, the Kingbird. So these will address the requirement because the topology, if you look at a carrier, they have everything in XML files and they have all geographical regions covered under different descriptors and these descriptors have to be either imperative or descriptive. You need to go through that and automate and that's the key and therefore we have a project called Parser to allow transfer between different formats and be able to ensure that those are applied and they apply to the FCAPS part of it so that you can get the besides high availability, you also have performance reliability and most of the mobile carrier always want 99.999% availability which is the key and that's what we are trying to start. So there's two components of it, the inside availability and you know multisite availability. So inside availability is as you rightly pointed out, OpenStack has not made a statement on how do you make a highly available OpenStack environment but there are people and you know us included who have created, put a framework around it and with our Helion carrier grade product you do have 59 availability within a single site and then when you go to a different other site then the VNF needs to be able to, today the state of the situation is that VNF needs to be able to provide that multisite high availability and but because OpenStack has not put a stake in this and in a couple of weeks we have the OP NFP summit where we're looking at different ways of going about doing it and I would put a plugin for OpenSaf, Open Service Availability Framework that has a very robust service availability framework and I would argue and would love the community to look at another open source project, OpenSaf, adopt it so that it's a common framework that we can use to protect the OpenStack platform and then VNF can leverage into the framework to provide availability at framework level as well. Just want to add a few more things. So high availability should be all about in the full stack, right? Of course we need the VIM, NFEI should be earlier available. There are efforts going on in the Neutron to make for example the Neutron routers to be in the HA mode and a multisite is another way of solving on the compute side. I believe there is also need for the VNF itself to be deployed in an HA fashion perhaps using, that's where things around affinity rules or perhaps anti-affinity rules or even that's where smart VNF placement might play a role in my opinion where you might need to place these VNFs at different sites perhaps for disaster recovery, right? And you add another question, I think we didn't indulge much on that. So I believe you would, my gut feeling is we will see a lot of these momentum around VCPI would pan out I believe in the next few cycles. At least there are tons of demos you might have seen in the last couple of summits. I hope that will be sort of the killer use case for NFEI in my opinion. I think that's what I would expect to see in this transition. Yeah I think just building on that in terms of adoption, I mean personally we are seeing huge interest in virtual CPI which is running those services in data center or cloud or for universal CP where those services are run on-prem on a standard 86 hardware. So again I mean we are, I mean obviously customers are in different stages it's a spectrum, so customers are still starting, they want to learn more about it, other customers, bigger service providers, you can name them, they are in more advanced stages. So we do expect some initial smaller deployments, prediction deployments this year. Well let me just add in the telco world things just move slow, that's just the way it is. It's slow because it takes us a long time because you know when you dial in your cell phone you want the call to go through. Do you want to say something and then I think? Yeah I just wanted to ask the HA question. Yes I mean if there are gaps, some of them have to be solved by the VNFs themselves. But if there are gaps I mean that's what we are filling in. I think the best way to do it is instead of doing it in a proprietary fashion if we can keep the spirit of you know stack and openness in mind I think that would be helpful. So with that I think we actually have run out of time so thank you and I look forward to more conversations.