 Okay, I think we'll get going. Good morning, good afternoon, depending on what time zone you're from. My name's Tom Nato, I'm from Brocade. Supposed to be doing this presentation with Chris Wright, who's unfortunately stuck in a taxi on the road up here, so he'll be coming in at any moment. I'm gonna be talking to you today about OPNIV, OpenStack, and Open Daylight, and where the sort of intersection is between those three organizations, and why they matter to people at OpenStack here today, and also where again, where the sort of intersection and overlap is between the organizations, where I hope we can collaborate rather than reinvent the wheel. So what we plan on doing is introducing the OPNIV organization, which was just formed. I'm on the TSC, Technical Steering Committee for OPNIV, Brocade's a founding member, as is Red Hat, and Chris is also my colleague on the TSC, at OPNIV, so we'll be representing OPNIV as part of this presentation, and giving you the download on that, and then of course again, explaining how that relates to OpenStack and ODL. Also, please interrupt me as we go. This OPNIV in particular is a new thing, and I think people may have a lot of questions, so feel free to ask questions as we go. So OPNIV grew out of a need in the network in this space. There was a kind of a hole in this space that service providers in particular were looking for, and originally they tried to address that need in Etsy, and you all may be familiar with the Etsy ISG working group which came out with the Etsy NFV architecture recently. Also recently that group has been rebooted to do subsequent work, although it's yet TBD as to what they're gonna be doing. But along those lines, basically operators have seen, in particular Telco SPs have seen what's been happening in the network, in particular increasing pressure to rapidly and more rapidly develop and deploy services, as well as turn them down, turn down existing ones. And large enterprises are also feeling the same sort of thing. At the same time, the industry is shifting towards SDN and NFV types of solutions, OpenStack being one, Open Daylight providing another complimentary solution. And so operators are also very interested in bringing their requirements to the party effectively. One of the things that I hear sometimes from operators is a need to bring their requirements and to have those requirements understood because these guys do have unique requirements when you look at that in the context of sort of the canonical data center deployment scenario that you might look at with OpenStack, for example. So we talked about the kind of shift in the industry that's happening and what is the NFV value to operators in this shift. So things like bandwidth allocation, cloud delivery models, and one of the interesting takes on the cloud delivery model is not necessarily the canonical data center, OpenStack deployment scenario. We're talking about cloud delivery of traditional telco services, maybe that are rewound or rebooted in a cloud context so that they could meet the requirements from NFV. Common standards for core elements is another important thing that people are looking for here. And by standards, I don't necessarily mean ITU, ITF standards, I mean standard way of doing things, standard implementations, which is what we're getting from these different open source projects. Also integration of existing NFV building blocks. So if you think about what OpenStack provides today, OpenStack provides VM deployment, VM orchestration, simplified networking that goes with those VMs and attached storage. Beyond that, the sky is the limit. If you look at Open Daylight, what's Open Daylight focusing on? Open Daylight's focusing on building its controller that can do detailed network configuration, monitoring management, and control plane functions. And so there's a bit of overlap between those two things in Neutron and perhaps a little bit in Nova. There's some work going on there now. But those things really complement each other. The issue is that they've not really been integrated officially anyway. Some people, I've done this, my company is doing this, and some other people are doing this, where we're integrating those two projects together along with other things that are going on. But it's largely driven by our context. So service providers again want to inject their requirements in this space so that the industry at large can come up with open source solutions around this that are driven sort of from the other direction. Also, again, ecosystem collaboration. So this is again something else that can't be driven from a single vendor or two that these guys are interested in. Bringing together the communities to not just integrate these things together, but maybe organically build something else out of these things, as well as testing. So conformance testing has long been an important thing for service providers. Interop testing as it was. And in the sort of old days of standards and protocol standards, for example, we had what effectively is called black box testing. You had an opaque box that implemented some interfaces on the side. I connect another box to that, and I want to make sure that the sort of state machines that govern those two things operate according to a spec. Things have changed a little bit in terms of what we call a standard now. You can very much look at HP, Morantis, Red Hat, Distro of OpenStack as a standard, as a de facto standard. And you pretty much will, if you set down one of those distros, there's no need to check for interoperability with itself. You can deploy any number of VNFs on that thing. And it should work fine. So what they're looking for is for the communities that are building those things to look at and explore some of these new NFE functions, but then also do testing within those contexts, those wider contexts, things like performance testing. So there are in scale testing. So there are some requirements being worked on and there are requirements that have been worked on at Etsy around this. And so they're looking for bringing that into the party. The other thing they're looking for in terms of testing is having a uniform set of equipment that for the NIVI, the infrastructure, executed as well. And this is something that's particularly difficult, especially given the new world of software-based everything. So if you're a company like mine, for example, or Chris's that doesn't actually produce, necessarily produce hardware in the space or is producing software in the space, actually getting all of that equipment in one place is an expensive proposition. The new organization proposes that a variety of the vendors get together. Oh, here's our speaker, our featured guest. Mr. Wright. Yeah, the mic's over here. There you go. And so what they're looking for is getting together that totality of equipment to actually have a kind of a uniform place to test that stuff. And again, along those same lines, doing service performance, so testing the NFVs on that performance and getting sort of uniform benchmarking is what they're interested in. Check? Yep. You wanna do this one? Sure. All right, fresh off a plane. So this is actually a cool slide. This is the one that is coming from the operators saying we've got, we're trying to rebuild our infrastructure and SDN is a buzzword, NFV is a buzzword. We're actually rolling back the clock about two years to the initial drawing or the initial creation of this drawing and trying to disambiguate what is SDN versus NFV as part of it. SDN is a component that helps deliver the package through your virtualized data center. But I think the interesting piece is the upper left corner, the open innovation. And the goal here is to build a platform, an NFV platform, steering traffic with an SDN controller that allows the market to produce new and interesting services. And we're already starting to see this so we're fast forwarding now back to today. And we see VNFs that are designed around a cloud infrastructure as opposed to the traditional hardware-based network functions. So this was sort of a dream two years ago and it's really becoming a reality which I think is the exciting part of NFV. That's it, that's a basic definition. OPNFV is, since I missed some of the beginning, OPNFV is building carrier-grade network infrastructure for service providers based on clouds, or based on cloud infrastructure. That's why we're here talking to folks here at the OpenStack Summit. And I think if we go into the next slide we have a little more detail. I guess the part that I'm not sure if Tom touched on already is the connection between OPNFV and the Etsy Working Group or ISG associated with NFV. And the Etsy NFV ISG is a sort of a standards organization that's produced a reference architecture diagram and details about that architecture. Really the goal of OPNFV is to take that architecture and turn it into a reference open source based implementation. Yeah, the other thing I talked about is the reference-based implementation, also the previous implementations don't necessarily have the service provider input, especially things like OpenStack which have different contexts. And this is very SP kind of driven, Telco SP. Right, really driven from the users, the operators, the service providers themselves wanting to reinvent how they post their own network functions. Yeah, I think I actually touched on these things. Yeah, I think the only thing that's not in here that I, that's here that I didn't touch on earlier is there actually are, I mentioned this earlier about organic efforts that will come out of the collaboration and the integration project itself. We're already starting to see those things, things like, things that have been talked about, you know, like KVM modifications related to NOVA that are related to these performance requirements, things like that, people have kind of worked on independently, but now they're being directly driven through this. But I think I talked about the other goals on here earlier. Yeah, that open reference platform, the notion of the platform is like Tom was saying, it's an integrated collection of work. So Linux, KVM, Libvert, OpenStack, OpenVswitch, Solidration Techniques for OpenVswitch, Open Daylight, all these different open source projects come together. Governance. So the, not unlike any of the modern foundations that are springing up around open source development, OPNFE has a basic governance structure. It's split into two fundamental different pieces. One is the sort of business half of the entity, and that's the board that maintains the budget and sets the overall direction, the very high level direction for the project. Then there's a technical steering committee who's responsible for really vetting the day to day project proposals and project life cycles of individual work streams within this effort. So we have a goal to keep the board as far away from us developers doing really useful work, and while we're brand new, we're so far we've been reasonably successful. Yeah, I should say too, I didn't mention this at the beginning. OPNFE is a Linux foundation project, just like ODL is, for example. And we and a few other people tried really hard to make it very much how ODL is set today, not how ODL was set originally, because we had some problems that we've worked through. So the organization today as it's configured now is set up to operate in the usual sort of open source way. And again, like you're saying, not board controlled, board sets sort of top level policy and developers actually rule the roost. Right, and of course the most important part is, while it is a foundation and there are memberships associated with it, it's an open source project. So anybody who's interested in being involved is welcome, just similar to, very similar to the open stack board and TC structure, and then individual projects and individual developers. The member community, who's come to the party to date? I think, again, I mentioned it's SP focus, so obviously Telco SPs are here, and you'll see folks like AT&T have come to the table. They've actually brought resources to the table, which is very exciting too. And that was actually originally a challenge, right? When these Telco guys showed up, they said, we don't have any developers, right? What are we gonna do? And so we worked actually pretty creatively with folks to try to figure out ways that they can contribute. And testing is actually a fantastic thing that those guys can do. And as I mentioned earlier, not only the testing of physical equipment that is difficult for folks like us to get a hold of in the community, but also just this sort of testing methodology, testing rigs, that whole thing is something that those guys have brought. That was very cool. And then of course, the rest of us have brought developers to work on the project. Which, you know, it's worked out pretty well, I think. And then I think other people have come to the party too. I mean, there's people that are doing cloud. There have been some academic folks that have come. Then some traditional enterprise folks have come as well. And I think those guys, the ones I've talked to anyway, are interested in this sort of uniformity that the project can provide to cloud services that they might buy and leverage. I was just talking to a guy at our booth just now about this, that he's interested in, you know, sort of, I don't want to say standard NFVs, but more uniform NFVs that are more easily quantified for performance, for scale, things like that. And that are cloud ready, not just repackaged, you know, traditional like route processor code or something. Do you have anything else? Well, the other, there's another group that's been expressing some interest in being involved, which is the financial services industry. So, ONUG was last weekend. And a few months leading up to that, there's been a lot of sort of discussion back and forth between our group and FSI about where we have common interests and common goals. Yep. And there's also, there is a white paper that the organization did put out that describes kind of the goals and what it is we're trying to do. And I think it's pretty well written. There's a reference here that might be hard to see, but if you just go to opniv.org, it's right in there under news or documentation. Opniv, as we were saying, is a pretty well supported, pretty diverse organization. You know, our companies are on here. Lots of other companies are on here. And it's kind of interesting, you see the diversity of people interested in making this work. You know, you've got chip vendors, you've got service providers, you've got software vendors, you've got traditional network equipment providers. You know, you name it. And so it'll be interesting to see what we can do. That's the obligatory corporate sponsor slide. And this is the, how do we really get things work? How do we really get things done? Or how do we work slide? It's an open community. So we consistently stress that. And it's interesting internal to this community, talking to some of the service providers who don't have a lot of experience working in open source communities. It's a consistent education process. We're defaulting to open, isn't necessarily the natural instinct. You take a community of people who've been spending a lot of time working directly with vendors or in standards bodies, some of which are not really completely open standards bodies. And bring them to a world that we're more familiar with and what we keep stressing is default to open. Everything is open. Everybody's capable of providing input. And that's really the important thing to stress here. Yeah, and one important thing is the open part in terms of transparency of what's going on. Some of the traditional telco guys are used to working in those other organizations where things are sort of done in the back room and, you know, in that way. And it's been kind of weird for these guys to kind of to work in this organization where like the TSC calls, for example, where we discuss things and make decisions for the community. And those are done completely in the open. Anybody in this room can call into that call. And that was a bit of weirdness for a while. And I think those guys are cool with that now. But originally they were like... Some culture clash. This doesn't seem right. The opium of the architecture. This might look familiar if you know Etsy, the Etsy ISG architecture. What's interesting about this is that the group decided to kind of adopt this as a reference but not like Margaret from AT&T said this well during the initial meeting. She said, we don't have an official architecture. This is a rule of thumb. This is not an implementation architecture. It's a guideline. And so this is kind of where we're gonna work. We've agreed, right? In that red box, we're gonna work on these things. And in fact, for the initial release, definitely within that box. If you can't see the diagram well, the bottom part of the diagram is talking about the base virtualization platform. So that's virtualized compute network storage. On the right hand side is some orchestration components. And as you go up the stack, you're looking at the actual VNFs that sit on top of this platform, the management systems associated with those VNFs and then the high-level orchestration that crosses the entire data center or the entire infrastructure. And the temptation in this group is to always move right up the stack. And that immediately turns into this arguing because not everybody agrees as you get further up the stack what those components look like. So as a pragmatic first step, how do we get things done? We've tried to narrow the scope to essentially the cloud computing platform that's core to an NFE architecture. Yeah, basically things that you can point a finger at today. Open stack, open daylight, KVM, things that you can go get off the shelf today and integrate together and then work going forward from there. And that's also helped with that, with those conversations of what is that? Well, we say it's that. And we can evolve that thing, right? It's a good starting point. We're already blurring the lines. As Tom mentioned, it's a reference, a rule of thumb and the boxes look neat. Of course, it's an architecture diagram but they're never quite that straightforward. So as an example, you have the VNF manager which is looking like it's out of scope but for an open stack based deployment, a heat template could look a lot like a component of a VNF manager. So we're pretty willing to blur the lines because we're doing implementation and we're not stuck on this idealized architecture diagram. Yeah, another example of that is the EMS that's in that picture, which is not in the box which actually could be open daylight, for example, which exists today. And so you kind of pull that box around and move it around. I think in a year from now, that figure will look quite different from what's there. And that's okay because it will work. In fact, you could say it's one of the goals. One of our goals is to create a feedback loop to the sort of standards side of the house to say you had these nice ideas and then over here is reality. Can we rectify these two? Yeah, exactly. Let's see. So we had our first hack fest a couple of weeks back where we sat down and went through, I think, do you have a list of, I think you had a list later. Yeah, I ended up deleting it because it was too long. It was too long, yeah. So we all sat down, sort of the TSC sat down for our first kind of, I guess it was an official meeting but everybody was invited. And then we also talked about, we had what we called lightning rounds where people proposed projects and to work on, and there were a lot, like 20, something, yeah. And what we tried to do was to find the commonality so that the other thing is the current deadline for our first release is what, like March or April. And that's a pretty aggressive deadline. I think we had six months from the launch date. So that was the other thing that we were trying to do is kind of hone things down to what is it can we actually do to declare success. And so that's still a work in progress. Although I think what's come out of that is a very strong and well-supported CI project, integration project where we are integrating OpenStack ODL and KVM in a continuous integration and all those sort of messy moving parts are being assembled in one place. So people are actually sitting down and doing it, which is good. And I think after that, we'll do fancier things, but I think the initial goal was to just get something working and I think we're heading that way. Have anything else? No. Nothing else. I think this was another figure that kind of graphically, more graphically explained what we've been talking about. Open on a V is really right now the integration project of those things up there. Actually, I didn't mention DBDK, Open Data Plane, or ZEN and ESXI. We also have OVS that's gonna be part of this as well, which is not in there, which is in the many more box. And then you can see the relation to other standards. So that was one of the other things. The service providers insisted that we introduce a closed feedback loop with other standards organizations that they work in. Etsy being one, ITF is another one that we do work with, as well as the other organizations. I mean, OpenStack and Open Daylight work with those guys as well. I think one thing to note here, there's an aspirational edge to this slide, which is showing a lot of different open source projects. I'm a really pragmatic person and I'm deeply biased. So there's a set of projects here that I'm personally not that focused on. And one of the hopes that I have for this group is that we can stay at least initially focused enough on a core set of technologies that we can do something and not be so focused on layers of abstraction to enable everything to be plugged in and plugged out. Ultimately, there is an interest in this community to have some plugability, but as you can tell by us being here, we're pretty focused on Linux KVM OpenStack as a core set of building blocks for this platform. Yeah, I think this was just a more detailed version of where things we think are focused right now. And also to show right now a common thread that runs through all three of these organizations, that being at OpenStack, the NFV working group. ODL has an SFC service function chaining working group. And then of course, OpenNNV is very interested in that progressing and also not just progressing but progressing, how do I say it, uniformly do it once, don't do it twice or three times. And so there's a lot of effort to get the people that are here to work with the people that are there and there and the good news is that most of those people seem to be the same group of people anyway. So this shouldn't be that monumental a task, I hope. Yeah, the last summit we launched the NFV subteam and some of us involved knew that this OPNFE was sort of evolving and coming down the pipe, but we were too impatient to really wait for it. We wanted to get things done already. So the NFV subteam is up and running, has a long list of things that are to be completed as some of which have been completed and what I keep saying, especially to the OPNFE group, if we're not aligned with that subteam and more importantly, if we're not fundamentally overlapping in many of the same people, then we're doing something wrong and luckily it is really, in many cases, they are the same people and we're working towards this common goal and it's just sort of this historical happenstance that we have two separate groups and OPNFE does have a broader scope than just OpenStack, but it's really important for us to be directly engaged with this community. And there are, by the way, there is a group of people here that are from OPNFE that are meeting tomorrow and you all are invited to the meeting. Anybody can go, I think, but it's exactly to do what Chris just said, is to prepare for the NFV working group meeting and to make sure that everything is kind of aligned I think that was it on here. And this is just a nice, simple visual of putting it all together. So, you know, we've mentioned multiple times the core projects. This is sort of what you would see if you deployed an OPNFE platform. It would be based around OpenStack, the compute nodes are running Linux and KVM, you've got an open daylight controller taking requests from the ML2 ODL driver and managing OVS instances on each compute node that are potentially accelerated by a project like DPDK. So just a nice, simple box diagram showing you how the pieces go together and that we're not dreaming up some radically different architecture or set of components. This is really just a simple set of evolutions of what's already there. And I think these are all part of the initial integration anyway. Yeah, with the possible exception of DPDK acceleration. DPDK is not, but everything else definitely is. Cool, so we're right near the end and we're on time. I guess we put this up here if you wanna get involved, if you wanna know what the heck this thing is, we wanna read more about it. All the, you know, there's some wikis here to tell you what, you know, get involved, what we're doing, how to get involved. Anybody can subscribe, all the mailing lists are open, I think, except for the board mailing list or maybe that is, but everything else is, the TSE list is open, there's a link to the weekly WebEx for the TSE if you wanna call in, anybody can call in and check it out, get involved. Are there any questions then? I think we've got like five minutes for questions. There should be a mic, if you can come up to the mic. I've got a mic here if you wanna, there's some mic, can you stand up and run over to the mic or can you hand that back? Is there a guy over here? Do you have any link with the IETFSFC work? Yeah, so that, that SFC work in ODL is actually, it's sort of like the, like we were saying with, with NIV here, it's probably half the people are the same people. So I, you know, Paul Quinn's involved, I'm involved, there's a variety of people. Bachman does both. So yeah, the answer is yeah, I think so. Question in the back, can you run up to the mic? Thanks. My name is Tal from Mounddocs. I have a question or maybe, maybe you can enlight us. We see open in a V or we see the transition to this one has a bit of a failure of OpenStack to deal with the telco world because if the OpenStack organization did support the telco, it would emphasize its work on neutron and all the stuff that are weak. So these guys come up and push OpenStack where it should have been. Could you change it? Why should we get there? Well, that's why we're here, right? To bridge the gap between the two communities. Yes, there's a historical schism between the initial efforts from driven from the telco side of how to get features into OpenStack. That's not the reason OPNFE exists exclusively. I mean, that's maybe one component to the background but it's, I mean, remember, OPNFE is this broader focused project spanning at least half a dozen projects, if not more, and it's trying to integrate them together where they each represent a core component that has feature gaps. So how do you bring all those moving parts together? And we do expect to have better, a more coordinated effort from a set of requirements that come out of an industry vertical into an open source community through this effort, through this OPNFE effort. So we're not just throwing random patches and requests at the OpenStack project, but really trying to work together with the project to evolve it. And there are other moving parts in here too that are not really appropriate for OpenStack that we listed that you wouldn't wanna work on here, that people here wouldn't be interested in working on. It's not that you wouldn't work on them here. I don't think it's an interest. The other thing too is the kind of use case you were talking about, the cloud use case versus the other use cases. There's been an interest here to work on that. What was your analogy? The cattle versus the pets analogy. And so that's also what the organization is trying to root out and bring to the surface that these things need to be worked on. Thomas Morin, Orange. Hey, Thomas. Hi, trouble maker. So the understanding that the goal is to have an open platform, as you suggested. On the other hand, you talked a lot about Open Daylight. So my question is pretty simple, in fact. What is your plan to make the platform applicable to context where an SDN controller possibly different than Open Daylight would be used or two scenarios where no controller, well, as a separate component to Neutron, would be used? Well, like I said earlier, it's a project with a broad set of interests spanning a bunch of different projects. To get something done, we're trying to narrow the focus to just a few key projects as a starting point. There are absolutely people who are interested in bringing other, remember it's an open source project, so other open source specific controllers. So OpenContrail or Ryu or Native Neutron integration or any of the possible alternatives are absolutely viable. The one that comes up the most frequently in this community is Open Daylight. So that's the one that we're focused on as a starting point. But there's nothing prescriptive about that other than gotta get stuff done. And there's, but I don't think there's a desire to build another controller here. He's kind of was in one of his questions. I don't think anybody wants to do that. It's let's integrate something that exists. That was the point, yeah. Yeah, my question was not so much about building yet another Indian controller, but much more about the level of stickiness you would have to things that would be specific to Open Daylight. Well, as you know, Open Daylight is pretty non-specific. So, well, I mean, there's a lot of room for it. Put it another way. If you're interested in something specific, why don't you come and talk to us and we'll figure out a way to get that into the project proposal. Sure, thanks, cool. Yeah, I mean, that's the whole point is for operators to come. And I think one of the earlier questions actually that this is a good highlight step is that OpenStack and even ODL were not necessarily good forums for service providers like Thomas to come to. They didn't really feel comfortable coming to those things because they didn't feel like they were hackers, devs, you know, that could actually come and get any traction. In fact, that was one of the complaints early on in OPNV. And that may be one of the primary roles of that organization is a place where those folks can come and feel comfortable to make things happen too. If you're earlier slides, you mentioned the 32, I think it was 32 projects or proposals. Are they documented or listed somewhere? The URL on the slide was hidden behind an image. Yeah, I think they're on the Wiki for OPNV. Yeah, there's a whole... They're definitely in the meeting minutes from that meeting. Okay, and if people want to submit their own proposals, is there a process for that? Or is it... There is, yeah. It's right on the Wiki. Project proposal. Yep, yep. Thanks. Pretty straightforward, pretty simple. Yep, if you need help, you can send us email. We'll help you as much as we can. So we already have two contributors. Right. Anyone else? Other questions? We're standing between you and lunch. Yeah, lunchtime. All right, thanks everybody. I'm gonna follow you. Thank you.