 Good morning, afternoon, depending on your time. Whatever time it is. It's five o'clock somewhere. Yeah, pop them if you got them. All right, so I'm Mark Collier with OpalSec Foundation. And I'm Heather Kirksey with the OPNFE project. And we're here to talk about the sort of collaboration between our two organizations I think has really been kind of ramping up basically in the past year. Yeah, I mean, we just see a lot of different use cases for OpenStack and different markets. And one of the big ones, obviously, is NFV and part of how users get to market with something like an OpenStack-powered thing is by combining with a lot of other technologies and a lot of other groups that are providing leadership. And OPNFE is a great example of an opportunity to kind of collaborate with another group. So Heather's going to tell us all about OPNFE. Yeah, so kind of as Mark said, OPNFE is an open source project that focuses on NFV. And I'm just kind of curious about the mix of our audience. What do we have sort of in the way of people who would raise their hands that they're very familiar with OPNFE as a use case for OpenStack, all right? Who would say that they're sort of moderately, you've heard about this NFV thing, but you're not entirely sure what it's all about. And who's kind of like, NFV, how did I wander into this room? Yeah, just since we do have some folks that aren't as familiar, NFV is really, it's a network transformation that the global telecom operators are undertaking where they are moving from a network made up of proprietary monolithic kind of custom built hardware elements and appliances and moving what was the functionality in those into software applications that can run in cloud type architectures. And so it's a pretty significant sort of change and approach in the industry. And the OPNFE is an open source project that's really focused on helping the ecosystem of networking providers to sort of make that transition. And basically we need to work together. So there are a lot of different piece parts that are sort of necessary to compose and build a usable NFV platform. And a lot of what we focus on as a project within OPNFE is doing that systems integration work of figuring out how those parts fit together and work together. And then also at the same time, what are the missing features and capabilities that are necessary in those upstream components to realize NFV use cases? Yeah, I think in the open stack side of it, obviously in the open stack community, there are a lot of developers and users that are getting more and more active, specifically around wanting this NFV use case to be viable within an open stack context. And so it's really good to be able to have the different folks that are part of OPNFE and that organization to be here. A lot of them are here this week, as well as participating in a lot of the sessions and discussions that they have and within their collaborative structure. So it's really not just kind of a let's meet once a year thing. This is like everyday collaboration. It's not really, am I in one community or the other? Many people are sort of in both communities and it's really trying to get to one solution to solve people's problems. It's gonna require more than just open stack. And so we're always encouraging people to participate of course at our summits, but also for anyone who's really active in open stack to attend other events and online discussions and other meeting forums within these other structures and communities like what OPNFE is doing. So you could talk to this slide. Sure, according to this slide. Yeah, so I mean obviously compute storage and networking is what open stack is all about and networking being one of the key words there. It's become really a somewhat of a de facto standard I think now within the major telco segment. I just heard that Verizon was speaking next door about how they're using open stack in production for their NFV work. And so we have a lot of the major carriers all over the world, SK Telecom, the list goes on and on. They're planning to utilize open stack as a component in their NFV story and as Heather was saying, the old world was very much like a proprietary fixed function devices in all kinds of data centers and smaller sort of central offices. And that hardware was basically impossible to upgrade. You had to rip and replace. So if you want to SMS to MMS, okay that's a multi-year transition, very expensive hardware you're throwing out for more very expensive hardware. And then when something else comes along you got to do it over again. So it's a massive benefit that these telcos see from going to something like NFV, but it's not a small undertaking, but given how big the telco market is it's really exciting for open stack to have a role in that. Because certainly when we started it, we had no idea it would be going in so many places that's kind of the beauty of open source. Now it's a really big use case. Yeah. And kind of to follow on a little bit on sort of the business drivers around that, we were talking about the movement from the hardware to the software. Part of it is just provisioning and management. It's brittle and it's hard, so it's hard to roll new services. And for a long time basically the introduction of a new service would mean a completely brand new network and network architecture. So I used to work for Alcatel Lucent now at Nokia. And when IPTV came out, we actually designed a brand new network and we sold the network, it was internally called Lightspeed, to AT&T to enable U-Verse. And so that was like a multi-year process of designing brand new sort of networking interfaces, figuring out how to deliver broadcast television over IP, sometimes digging up streets to lay new fiber and stuff. And by the time we got done with that, do you know what happened? Netflix. So after like a six year transition of designing this network, implementing this network, putting it in, putting the stuff in, it was just in time for a completely new model of the service consumption. And so that's not really the way we can keep doing this going forward. We need to be able to sort of react more quickly, have less risk, sort of de-risk the ability to invest in new applications and services as an industry so we can sort of focus on delivering more interesting things rather than managing a bunch of pieces of hardware. There's actually a popular expression which is that the best way to predict the future is to plan for it. I actually hate that expression because I think that open source and collaboration is the best way to make sure you can respond to the unknown which is what you're definitely gonna hit when you get to the future. There's no way to predict the future. It's actually a false idea. And I think that, I've never heard that example before. That reinforces my belief that that's a bad expression. I'm gonna agree with you. So I just talked a little bit about OpenFV. So we're focused on sort of a carrier grade integrated open source platform. And what we're really interested in doing is help advance and accelerate the introduction of NFE products and services. So sort of like, what is the industry needing right now and how can we help do that? So I've got a collaborative vision right here. You can read the slide. Is there anything that you wanna say? Yeah, I think that this is just an attempt to kind of encapsulate in a sentence kind of the general idea we've been trying to convey which is people, there's a huge opportunity out there. People wanna, in the telecom world, virtualize their networks. And it's hard sometimes, I think, if you're coming from the IT or cloud world to just understand how big and massive this transition is. The telecom industry's over a trillion dollars a year. And that's actually a huge chunk. I think it's like 40% of the total IT budget goes into telecom. And if you're in telecom, you think about that all the time. But if you're in kind of coming out of the rest of the tech world, it's just something that's kind of foreign. But as I've learned more about it, I realize this is just an incredible opportunity for OpenStack if we get the collaboration right. And so we're working on that now. Yeah, and so just a little bit of market research background. We had a heavy reading do a report for us heading into OPNFES summit last November. And some of those sort of interesting things are that 60% of the telecom providers are actively exploring NFV and beginning to work on implementation around NFV. 50, more than half said, this is good. Thought that OPNFV would actually help do acceleration. 68% cited OpenStack as very important to the success of NFV. So the telecom operators out there who are looking at this network transformation obviously are recognizing the important level. Those are very smart people. Yeah. And then just kind of an idea where the industry is around this, it's growing, like people are doing stuff, but it is still relatively nascent. The 26 are sort of in the testing proof of concept phase and 19 are actually sort of beginning to fully deploy. So we really are at the beginning of kind of a long journey together. And I'm just, let's go through here. So looking at some of the integration points that we have as organization, obviously there's a large overlap of members, a large overlap of our end users as well. So AT&T, the super user this year, obviously they are doing a lot with NFV and a lot of what they're planning to use OpenStack for is around their NFV transformation. And then we also, we do a lot sort of at the board level to sort of collaborate, we're doing stuff at the kind of foundation staff level around marketing plans, little pitch. We've got lots of collateral actually in right outside the room. So go pick up some of our joint collateral that we've done together. And then- I'll just give a shout to Kathy Ketchiatore. She's right there. He's gotta be there somewhere. Yes. From the OpenStack foundation staff side just puts an amazing amount of effort and skill into doing our part. So thank you, Kathy. She's worked on a lot of the collateral as well. Well, we're out and I'll give a shout out to Brandon Wick who's been working alongside Kathy on that. So- Awesome. Yeah, and then obviously a lot of what we really are looking to do is really help facilitate the collaboration between the technical community since that's where code gets written, the rubber hits the road and the important artifacts are actually produced. And so that's been a large topic of discussion amongst all of us trying to figure out the right way to get the communities working with each other. Like what was the- You at lunch had a sort of a funny quotation from I think one of your members sort of about sort of not being really able to understand sort of the telecom people that we kind of speak kind of funny languages. I think it was Monty who usually, he'll probably just appear when I say his name because he's usually everywhere at once. But Monty Taylor's been around OpenStack forever and he said, he started a conversation in here like just a series of acronyms and you're like, I've no idea what you said and then they explained, he's like, oh, what didn't you say so? It's just like this Linux networking thing. So there's kind of that translation between worlds that has to go on. The OpenStack world is very much kind of coming out of Linux and Linux networking concepts and kind of computer networking and not necessarily as steeped in the acronyms of the network world from a telco perspective. And we have our own acronym soup in OpenStack land but it happens as well in telco. So just it's taken some time for everybody to kind of get on the same page but what all the words mean? It turns out they're actually talking about the same stuff. Usually it's just slightly different words. So that's getting over that point has been really helpful. Yeah, we really do like acronyms in telco world. All right, so we've done a variety of sort of things this week sort of around that some luncheons with various PTLs, getting input into understanding the product working group and its role in OpenStack. I feel sort of bad. I mean, we've been involved in a year and I didn't really know that the product working group even existed, which. That's totally normal. I mean, we're constantly evolving in OpenStack how to kind of do open source and new and better ways. And some of that involves creating new teams and then when we create the new teams, letting people know about it and we get together twice a year, which is awesome but in between a lot happens and it's sometimes a challenge to let everyone know, oh, we've got this group and this is their function. Here's when you can get involved but these summits usually there's a huge burst of collaboration that happens right after because all the people find out, oh, you were working on this, so was I. Let's talk next week and so it's great that you guys can get active in our product working group. It's actually been a big help for OpenStack. So, and that's been one of I think the lessons for us is it can sometimes be a bit of what I'm looking for. OpenStack is such a large community. It's sometimes a little bit difficult to figure out the right ways to get engaged and get involved so it's been very useful to begin to get information on some of these other processes and things going on that we as a community can make use of to help sort of the OpenStack community better understand our use cases and what we're trying to do. So this is sort of a kind of joint diagram sort of pointing out sort of our sort of stack here. So you see obviously OpenStack's sort of key part of it with across the network and the compute and the storage virtualization and control and if you sort of look at what OPNFV does we do a set of things, right? So we take sort of pieces of OpenStack. We also take things from other upstream communities such as SDN controllers, OVS, KVM, Linux, various automated deployment tools around that and we actually do sort of integration work amongst all of those pieces. Different communities tend to be heads down sort of trying to get their software working and aren't necessarily thinking about sort of its integration points with all these other pieces across the network. So that's one of the things we really do is focus on integration and deployment. The other thing we do is a lot of testing. So to realize some of these features it requires sort of all of those pieces to be put together. So doing testing at a system level to see, all right? We had these blueprints that we got accepted into various OpenStack projects. We had some things that we got accepted into OVS. We had some things that got accepted into the Linux kernel. Did we actually manage to achieve what we set out to do? So that's kind of what we do with a lot of our testing. And then finally sort of the work that we do then to take those blueprints and specs and changes and enhancements from a fee perspective back into the upstream communities like this one. So we were gonna kind of maybe highlight some of a couple different projects with touch points here, some of which are sort of new and some of which have been actually pretty successful in working with each other. So one of our projects is called Doctor. And it was looking at fault management and monitoring and fault alarms. And sort of when we started, the ability to sort of get alarms notified was on the order of several minutes, which depending on a lot of enterprise applications is perfectly fine. But for a network that runs 911 perhaps is less so. So we had a doctor team that identified a number of different, you sort of across multiple projects and even a couple other upstream communities of sort of just some specific changes that would be able to make that work better. Some of which got into Liberty, some of which are in Mutaka and some of which are still in progress for Newton. Sorry, I must call it Neutron. And got the fault alarming down to order of a second. So it was a really, and then that actually, you can think about it, there are probably many other industries just besides the telecom industry that can make use of sort of that improved fault management. So it's sort of something that's greater for the, good for the greater community as well. And so you can sort of see a list of the various blueprints that we had right here that went through the doctor project. Yeah, and I'm sure most of you are familiar with OpenStack process, but blueprints if you're not familiar is part of kind of the pre-work that goes on to specify what we want to develop or what somebody's interested in seeing develop as a feature within a future OpenStack release. So it's part of that that specking process. And if you're the product working groups, another sort of level to engage in, but this is a specific tactic, if you will, that if you're not familiar with, it's important to learn about as you start to want to get involved in the upstream OpenStack community. So it's been awesome that the OPNFV communities learned the ropes in terms of some of the idiosyncrasies of our process. And blueprints are a really good sign that you're contributing some requirements. All right, another project, and this one is a new one. There was actually a presentation from Ian Wells earlier today on this project. And this is a project in OPNFV called Not Ready, which is looking at some of the networking requirements that sort of our constituency has around, you know, around what we're trying to do. And, you know, I think this is very interesting because, you know, for most people out there, networking is just one of those things you have to get in place so you can run your cool, interesting applications. For our industry, the networking is the cool, interesting application, right? So it's, you know, it means that there are harder and stronger sort of needs around sort of some of the networking capabilities and requirements in order to be able to deploy sort of the level of service that you, you know, depend on every day when you use your cell phone or when you, you know, get data on your phone or in your house. So it's, you know, there are a lot of sort of, you know, working and evolving sort of around this as well. That sounds good. I think we have the next ones on Tacker, yeah. So, you know, one of the things that we talk about in OpenStack is for a while, is philosophically we started to think about as an integration engine because if you really, people have always tried to get their head around what exactly is and is not OpenStack. But if you look at OpenStack Cloud, it's always integrated other components, other open source components frequently like KBM for the hypervisor and so forth. And early on, you know, there was always this confusion that people thought OpenStack was a hypervisor, which was a sign that, you know, we hadn't done a good enough job yet to explain what it was. I think we got over that one now. But now we think about, you know, other points of integration and in some cases, that means introducing a new project that really helps fit a specific use case for a market, in this case, you know, NFV with virtual network functions in order to integrate those in sort of an OpenStack native way. This OpenStack Tacker project was created. And I think it's off to a strong start. And so for those of you who are a bit newer to some of our acronyms in nomenclature, VNF, which virtual network function, is the name for the application itself, the networking application that runs on top of the infrastructure layers. Yeah, I think that's a really good point that probably is another area where it gets hard sometimes with the language and the words to, for people to grasp is that, what's the app on the network? Well, the network is the app. And as you said, and I think that helps me think about it a little bit better. I mean, network services are the thing that essentially telcos are in the business of doing among other things. So for them, it's not a secondary sideshow. It's a massive business and it has to work and has to work right and reliably and quality service and all these other things that we obviously need in any networking environment, but it kind of takes it to another level when that's really the service you're offering and selling in a lot of cases. So here's just a little bit more information on Tacker from the Tacker team. And then obviously we've got a number of shared end users which we mentioned earlier, AT&T, China Mobile, Docamo, Orange, SK Telecom, Telecom Italia. So we have a common end user base as well. So I know that OpenStack has a number of different sort of markets and customers across different segments. We're a bit more focused and concentrated in the telecom world. But they're coming together, they're not necessarily different anymore. And then we kind of wanted to leave some time for questions. So we'll sort of have kind of the, you can see some resources up here. And as I mentioned, there's some collateral out there. And we are having a summit in Berlin in June. And so we definitely really like to encourage your various OpenStack people who might be interested in some of these use cases to come to that. I know a lot of maybe kind of like long time stackers are sort of like, what is all this weird telecom stuff? But if you think about OpenStack being used as the foundation for the next generation of global telecommunications networks, the things that connect your phone, your laptop, your Chromecast, whatever you have in your home or sort of mobile devices with you, this is what we're doing. So I mean, I think it's actually a really cool, interesting thing from a developer perspective to think that what you're working on as OpenStack is a thing running the world's networks. Just one more comment on the joint users and the user examples. So you mentioned AT&T, they gave a keynote on Monday and as well as some breakout sessions. So all those videos are online now and SK Telecom gave a keynote back at the Tokyo Summit. So I'm always plugging our videos because it's awesome that we were able to have sessions and share that content with people that can't attend them. Even if you're at the summit, you can't attend every session because there's so many parallel things. So there's a treasure trove of information out there from past talks and you can go onto YouTube and find them and stuff. And it's good to, if you wanna look and see some talks, you can see. All right, so we've actually, we've got 10 minutes left for questions, so. Yes. So what is the relationship between TechCare and Open Search Manual? What I'm saying that it's leading by Etsy now. I was hoping, I wonder if, I don't know if we see Jose Francisco in here. I'm sorry. We can ask them. Okay. All right. We have the PTL here, so I didn't realize we had royalty in our midst. All right, so we are two different manner projects at this time, but we do interact at common forums that is general interest to collaborate on common things like libraries and elements of manner. But we are different projects at this time. And if you could direct all your future questions to him, he knows all the information. Thank you for coming. Any other questions? Here we go. Samir from STC. My question is actually about the timelines. You know, the main target of OP NFE, as we understand, is to build, let's say, reference implementation model that all, let's say, vendors will comply to it. But then now I didn't see, let's say, timelines. What are the targets? Are we going in line with Etsy standardization as well? So this is mainly my question. And what do you mean timelines for what? To get the outline or the output of the work so that we have at the end of the day one reference implementation model that we can deliver to vendors here what you have to do. So I'm not actually sure that we're ever going to end up with one reference implementation model. If you look at what we did in our Brahma Putra release, which was in March 1st, there were, we actually delivered sort of integration with three different SDN controllers, for example. Onos, OpenContrail, and Open Daylight. And those are there. We were able, we would deploy with vanilla OVS as well as an enhanced version of OVS, kind of same thing for KVM. There are kind of just other sort of pieces where there are multiple options out there and we're doing, from an integration perspective, we're not necessarily trying to pick winners as OPNFE. We're trying to facilitate kind of the innovation from a community. So I think saying that there's one platform is probably, you know. It's not the target. Well, I don't think it reflects reality. Just because there are so many choices and components may be 10 years from now, will be down to one SDN controller. And we've realized that that was the SDN controller that won. But I mean, I think in the meantime, we had this concept that came out in Brahma Putra scenarios, which are sort of different kind of flavors of the platform that we build that we run tests against. And so, and that's something that we're kind of continuing to take forward into our Colorado release. But specifically around output, our next release is Colorado. And it will be coming out in the, what did you say, Chris? After summer. Late September, most likely. Thanks. Yeah. Any other questions? All right, well, it's definitely five o'clock somewhere and I think that's here. So I don't know if anyone else is getting thirsty. It's an open source community. We're always thirsty. The thirst has never quenched. Thank you all. I hope we quenched your thirst for knowledge about NFP.