 All right guys, we're gonna get started now. So we have a Red Hat panel with some Juniper folks here. So it's gonna be more of a conversational presentation, but before we get started, remember, come here and fill up, you fill out your raffle tickets to win the Amazon Echo after, and then we'll do the raffle. And then another note later tonight, we have the open control user group meeting at Fenway Park, followed by a dinner event there. So I'll let you guys go ahead and introduce yourselves. Great, thanks. Yes, so just before we get started, if anyone has questions, this is kind of an open conversation. So if anyone has anything that they wanna do, just please come and use one of the two mics that are on the side here. So, oh, so yeah, just a quick overview of what we'll talk about today. So, what do we mean by when we say upstream and downstream, that's gonna be a pretty major component. So a show of hands, who knows what upstream and downstream is if I use that terminology. Cool, so we got about half the room. So yeah, so we'll define upstream and downstream because it'll make a lot of sense for the rest of the presentation. Why working upstream is important and what the advantages of that is. Why collaborating with other companies makes sense. So the whole presentation is about how Red Hat and Juniper have been collaborating in an upstream ecosystem. The benefits for everyone. So how Red Hat and Juniper in the community and everyone gets a benefit out of that work. We'll briefly look at how the partnerships work. And then, like I mentioned, it's basically an open discussion and we can just kind of take it as we go. So yeah, so who's talking? My name's Dave Neary. I work for Red Hat and the open source and standards team focused on SDN and NFE community strategy. I'm Life Madsen. I work on the NFE PE team at Red Hat and I'm the team lead for DevOps and CI. Yeah, my name's Michael Henkel. I'm working for Juniper Contrail and right now I'm driving the control integration into Treblow. And my name is Gil Barros. I work for Red Hat and the OpenStack BU. I'm a partner product manager specifically with working with Michael. So what's upstream and downstream? You can take over. Oh, thank you. So the reason we use upstream and downstream is kind of the water cycle metaphor. Code, you can think of as starting a developer's brain, it becomes code which gets committed to a community repository. That community then releases that code as a project and that project is used as the basis for product offerings that eventually get delivered to customers. So you can think of it as a kind of a flow from developer brain to customer data center. And that's, so when we talk about the upstream community that's the place where the code review happens where it's the open source community where the code is written and developed, downstream community is where it's consumed. So where it ends up, we create products and provide solutions to customers. That's basically it. There are a couple of other metaphors that I like but this one is the most well-known. Cool. So just before we get into kind of the nitty gritty and the why, let's kind of look at a positive feedback loop and generally how this upstream and downstream dichotomy works and how that results in products. So you can think of this line at the top, it's the upstream and it's the flow. It's where you have your commits going and it's just like kind of a continuous timeline. There's these changes from the community and they're being merged and so it just kind of keeps going indefinitely. But as a product person, it's hard to maintain to build products around that and provide the appropriate support for your customers. So what we want to do in a downstream model is to periodically snapshot and effectively version that and so we can kind of stabilize that functionality. We know what's in there. We have a little bit more control over what's going in and stuff like that. So in our example here, we have version one. It's effectively a snapshot. It's a commit that we take and we start with that. So during the downstream development, we may have some additional testing that we have specifically for our partners or for our customers and things like that and an issue may be identified. So during this time cycle, we have an issue identified. So what we ideally want to be doing is instead of fixing it downstream and maintaining that out of branch and having to have all the lifecycle around that change, what we want to do is work with the community and land the fixes upstream. So we work with the community. We make sure that the fixes aren't providing other regressions and other problems. So we have a wider swath of people looking at our changes. That's kind of the advantage of having open source in general. So we work with the community and we land that fix in the upstream code first. And so now at this point, we can cherry pick that specific change back into our downstream. So we have a change, but that change is not different than what is landing upstream. So that change comes into our downstream and we've now resolved our issue. And we can do that several times. So we can keep pulling these changes down to stabilize our downstream product. And then what we can do is, you know, at some point in the future, when we need to do a next version, we can create a, we can do the same thing. We can create another snapshot. The nice thing when you do it this way is that all those changes have landed upstream. All those fixes are there. I no longer, once I resnap shot from my next version, all those changes are there. I don't have to worry about pulling them in. I don't need to rebase. I don't need to worry about merge conflicts. They're just, they're already there. They're already dealt with and away we go. So the positive feedback loop basically results in, you know, Red Hat and other companies work with, you know, this is what we call an upstream first model. So that's effectively what I just showed. You know, all the work is done with the community upstream and any new functionality lands first in that upstream community before you pull it into the downstream. Bugs are found in downstream testing, you know, again, push all that up so that I don't have that kind of overhead of maintaining it going forward. No forking of the code, you know, from, you know, kind of that negative connotation of forking rather than just the GitHub terminology and allows, you know, for companies to stabilize the code and provide that functionality and support to their customers. And then you do that periodic snapshot of new releases. Yeah, microphone. So one of the key things is when do we create the downstream for, right? What's the milestone alignment? Like for example, OpenStack has set in milestones, right? For the releases. What is the right time to basically take your downstream for, right? And start cherry picking fixes, feature freezes or whatever be the milestones towards your own. Oh, we get into that a little bit later, but typically companies would take off a release, right? No, sometimes you might, for example, our Red Hat OpenStack platform, we try and have more of an agile development of the product, so we will have, we will start downstream testing, product testing actually earlier even than a feature freeze in the OpenStack cycle so that we can get a product out. We have confidence in the product because we're testing it along the way. Yeah, absolutely. I think that's part of how we're doing it. We're contributing early, right? I mean, our engineers are working upstream, but also we start working with our branch, if you will, for our productized version of OpenStack early and going through our QE process, and that way we may find bugs sooner than after we create a product, right? After we release. So that means that a lot of those bugs that you're like, what, the dynamic that life identified where you're finding issues and you fix them upstream, that means that you're getting those fixes right into the release that you're going to be shipping to customers, right? So you're getting them in their area lower cost. But why do we do it? What's the importance of working upstream? Why do we bother? It seems like a lot of work. So let's look at four different ways that companies typically consume OpenSource. And looking at the four, you can kind of think of these as I'm going along as discovering the four freedoms of free software incrementally, right? So you start by using the code, branch and modify. So you take a snapshot of upstream code and you just modify it to fit your needs. Updating regularly is realizing that you have the opportunity to distribute, to get, participate in the development, right? So you're taking what comes from upstream. Contributing back, you realize that, oh, I have the opportunity not just to take, but also to give. And then working upstream is the idea that you can get value from collaborating. So these are the four kind of, as I said, they're kind of the four freedoms of OpenSource, the freedom to use, investigate how it works, to make modifications and to redistribute those modifications. So looking at the first one, the main issue that you have when you try and branch something and modify, and this is probably the most frequent way that people take code is I'm developing an in-house application. This OpenSource code over here fits my needs to 99%. I'm going to just add the feature or fix the patch or do the integration with some other piece of code that I have, and then that's going to live on for the lifetime of that project or whatever. The issue that you have with this, and a few people in the telecommunications industry have actually run into this, is that if you take, for example, an OpenStack kilo, and you make a lot of changes to that OpenStack kilo, you kind of end up getting stuck, right? You may not be able to go to a newer version of OpenStack because your features, you need them, they're tied to kilo, and the cost of porting those features forward is prohibitive. So you end up with these, you're missing all of the benefits of this being an OpenSource project, and one commentator a few years ago called that Unleveraged Potential. It's all of the code, all of the security fixes, all of the bug fixes that go into the upstream you're missing out. So you end up with a double cost. You've got the cost of the work that you do on that OpenSource project and the opportunity cost of the upstream work that you're missing out on. So typically, step two, you say, well, this is free code, right? I can look at how it works, I can copy that code back into my branch. So you do a regular re-merge, right? You take all of the code that's gone in between kilo and L, L, help me out here. Liberty, Liberty, the Canadian one. I win. All the code that's gone in between kilo and Liberty, and you take your changes and you put them on that. And that's a fine approach, except it's not a one-off cost. You end up having to do that very regularly. And typically, as you go along, you add more and more code to your copy. So you end up diverging, and that cost of merge becomes bigger and bigger and bigger. You end up with this crippling debt of maintenance over time. And so eventually companies say, well, you know, a lot of these codes are on differentiated heavy lifting. We've done the work, there were features that were important to us, but maybe others in the community can benefit. And so you get to this, we'd better contribute back to the community. And that's the frame that people use, is kind of using it as a gift culture, right? This is a gift that we're giving to the community. We're donating code. And again, this is a great thing to do. It's a positive step, but it doesn't come free, right? The idea of giving code to the community so that the community will take care of the maintenance and you don't have to worry about it anymore is a flawed idea, because not only have you done the work to do the feature, you've had the cost of merging and keeping your code up to date, but you also have community overhead. You also have things that the community expects you to do that you wouldn't otherwise have to do. There are many examples of this. One of them is if you're developing a product, you're typically to address your point earlier, you're typically going to want something that you think is fairly stable. So a standard branching mechanism in a community is you've got a stable release branch, which has incremental versions there which are only fixing bugs. And then you have a development branch where all new development work is done. And as a vendor, you probably want to create your product off the stable release. You don't want to ship experimental code to customers. You don't want to have kind of the increased QE cost of testing a moving target. And so you take the stable release. However, the community wants code on the tip of the trunk. They want code that's committed and rebased on master because they've already forgotten about the stable release. Well, not quite, right? But if you were going back to two releases ago, you probably don't have anybody paying any attention to that. So if you're proposing a patch to like Liberty now, it's going to rot in Garrett for months before anybody gets around to it. And it's probably going to be rejected. And even if you put it into that, now you've effectively put the burden on the community to forward port the patch up to master because then. Well, you haven't because they're going to ignore it. They're going to ignore it. But even if they accepted it and it just doesn't really work that way. You'll get a minus you pretty quickly. So you end up with this situation, which is kind of what we call upstream first. You do your development against the master. You do your development against the upstream project. You merge code from the master branch onto your development branch very regularly so that you always have a clean merge from your development work onto the master. And then you get that code onto the master as soon as you can. That reduces all of your merge costs. It reduces your maintenance cost over time. But then you still have the problem of, well, what do I ship to my customer? So you take once that code is merged into the mainline, you then have an opportunity to backport that code and put it on your vendor production branch, which is the stable product that you're delivering to customers. This is what we do upstream. This is we will backport security fixes. We will backport bug fixes to a stable branch. They're not only put on the stable branch. They're primarily put on the master and then backport it back. And so this is the best way to work with open source, but it's not without problems. And I think Michael here can speak to some of those problems. The first of which is that when you're building a product, particularly if you're integrating multiple open source projects, it's very, very difficult to synchronize your product planning and the upstream open source project planning. Release dates can be unpredictable. Releases slip all the time. You can have a release of one project which is coming out in March, another project coming out in June. And you have to decide, well, do I release my product with the newer version of project one and the old version of project two, and so on. So you're kind of building a castle on quicksand. It's a moving target. You've got to figure out how to aggregate and reduce the risk of that aggregation. Also, it's a ton of work to get code upstream because the community is going to take time to review your patches. And they might not be aligned with your goals at all. So there's a risk that they may just reject your feature proposal out of hand. But Michael, maybe you can talk about some of the. I mean, one thing also to mention perhaps is that if you build a commercial product out of an open source project, then you will have at some point paying customers. Those customers, they request features. Yes. And they don't care too much on what's going on with the community, what is upstream first. And so you have to somehow realign between customer feature requests and all the community processes. And that's sometimes a little bit hard to achieve. Right. We spend some effort trying to educate customers to the benefits of upstream first. But a lot of times, they still have deadlines. They still have production releases. They still have things that need to make them money that they can't wait for. They want to see the code. They want to see it in the product. And then in addition to that, those customers might run on an earlier release, because it's labeled as LTS or Longlife or whatsoever. And they're not going to change to the latest release. So you have to backport that kind of features and patches to that LTS release, because there's no choice. Yeah, absolutely. The LTS releases add an additional burden, because we have an interest in making a release have a long term, a long life for customers to be able to stay on a stable branch for a long time. But they also want, as you mentioned, oh, I want you to do this new thing also, but stay on my long term. So there's some negotiation to be had. Yeah, and it's not unusual to have up to 12 months from code being written that implements a feature to actually having that code released, to having that release integrated into another project that depends on it, to having that code delivered to customers. So yeah, there are difficulties, definitely, with the upstream first approach. And we were saying before the session started that one of the things that you have to do a lot is actually just say no to backporting features. And so we have people who that's basically their default response and that's their job is to ensure that we don't take on an undue maintenance burden unless there is a really good business case for it. And that brings us to the really good business case and building partnerships. Could I ask a question before we go on to that? So what you said, Dave, makes a lot of sense. Question is, is there ever a time when, say, there's a bug that gets found and we have a fix? And based on what you said, we put it up in the upstream first and then bring it down to the product. Question is, how long does that usually take? And has there ever been a time when it takes too long and we might make an exception because the customer needs the bug fix immediately. You put it downstream first and then do it upstream. Has that ever happened? Well, Gil is the product manager in the room. I'm going to defer to him on that. Yes, you want more details, I assume. Yes, so I think security fixes are actually a good example there, right? I mean, the security fixes are very important and we want to ensure that the shipping stable product does not have vulnerabilities that would affect customers. The community will find issues, will find problems, they'll do the work upstream, but a lot of times because of our investments in these communities, the people working on these fixes upstream are either Red Hat employees or Juniper employees or basically the people who are working on the productized version. So a lot of times the development is concurrent where we know how to fix this. We've had the communications about how to fix this so we're working both sides. And as you said, yes, sometimes, assuming we don't break any embargo dates, the releases will happen on the same day, almost immediately, right? I mentioned embargoes, a lot of times the security community will give ourselves or themselves a certain amount of time to fix a bug or to fix a security fix before it becomes public. Say Apache has discovered a vulnerability and it's not a publicly noticed vulnerability. So instead of immediately going out and publishing it, they will communicate with the key players and say, we just found this, we need to find a fix, let's say give ourselves two days to fix this and then we will announce the vulnerability and the fix at the same time. That makes it safer for customers because there is a smaller breadth of people who know about a vulnerability and it makes it so that we release the fix at the same time. But for bug fixes, yes, sometimes we will be working upstream but a customer needs it yesterday because there's a system that's down and it's costing them money. So we'll give them an early release, a hot fix or something like that so that they fix their problem. With the understanding that fixes your problem this way may not be the fix that actually lands upstream and we will work with you to make sure that the upstream landed fix, if it is different for some reason, also solves your problem and you can migrate to that easily. Yeah, because you're not always gonna have the engineers who are working upstream in those particular projects where you submit the issues. They don't have any timelines or constraints in order to get something merged in. So it can take some time and especially if you're not fully engaged in that particular community and they maybe don't know you quite as well, maybe it becomes slightly less prioritized or maybe they really wanna spend a lot more time reviewing the code and making sure that the changes really match the style of the project and so you can have some of that delay and back and forth. So yeah, I mean it makes sense you're gonna end up with a hot fix potentially pulled into your downstream in order to get the problem so that your customer isn't basically increasing support and stuff like that. But what you'll have to do is make sure you're tracking that change in your downstream so that when the upstream change gets merged, if it is different, that you effectively roll back that hot fix and pull the actual change down so you're not diverging. Okay, building partnerships. So a big part of making this community work is that there are multiple groups of people working on different projects, different products and we want to make sure that we're providing a solution that's interesting to customers, right? I mean, if what we're providing is not interesting to customers, well, it's a nice academic achievement but it's not going to put food on anybody's table. So when we worked with Juniper in particular, we had specific targets. In this case it was we wanted to do an integration of Juniper Contrail with OpenStack and it was more of a stretch goal than we've in the past done with a lot of other SDN integrations where we wanted to fully deploy Contrail, not just the compute and not just the client but also the backplane. So there was a lot of sort of understanding what the partner requirements, understanding what customer requirements were working with Juniper to figure out how we were going to fit these in our roadmaps, right? I mean, we were talking about multiple different roadmaps and it's an interesting challenge and I think a big part of it is learning how we each work, right? I mean, OpenStack Red Hat has been doing the upstream first model for over a decade, two decades, a very long time and that's not necessarily whatever it does. So it was an interesting, I think learning experience for both of us. It was a learning curve for Juniper quite a lot because, I mean, Contrail is an open source product. However, it doesn't have the same level of community as OpenStack, for example. And although development is a little bit different to what's happening in OpenStack, so when we started, and it's totally separate from OpenStack, so there are only very few integration points like the Neutron plug-in, like an Overvift driver, so that's where we paid attention to what's going on upstream. But now all of a sudden that we started to integrate with Triblo, we had a much more touch point, so we had to look into how is the community working, how is upstream working, and that's where Gil provided a lot of help introducing us into that new way of working and it was quite an experience, a very pleasant experience. I really enjoyed it so far, and it's, I mean, there's a lot of benefit because working upstream, having such a big community, is spreading the word for the product. People are looking through the source code and see, okay, there's new SDN product, it's part of upstream, we can deploy it. And they're contributing to it also, right? I mean, as you're putting code up there, you're having multiple eyes look at it. Absolutely. And these people who don't work for Juniper are making recommendations and suggestions on how to implement something differently, an improvement. It's some kind of reputation, I mean, if you can say, okay, my integration is upstream, that means it's not a point solution, it's something which has been validated, which has been reviewed by a bunch of people, and yeah, it's finally good for the product itself. It is. An interesting anecdote from when we were starting working together, Michael was one of our main touch points on the engineering side, on the solution side, and I had managed to convince Michael that he doesn't need a person to call in engineering at Red Hat, right? That he should just go to IRC, just like go to pound triple O, and someone will answer your question, right? You don't need a phone number, right? And Michael got it, right? He was submitting code, he was asking questions, he was, and we're on a call, we have joint engineering calls, and one of his peers from a different department was hammering me on like, no, like I need an engineering contact at Red Hat because I have questions, and I was about to say, you really need to go to IRC, right, like you really need to go to pound triple O, and before I got the word out, Michael said it, and like I felt vindicated, you know, it's like, we've finally gotten here. Yeah, I mean if you want to play upstream, you have to use the process which are in place, and I mean as I said, it was really the first project for Juniper where we contributed that much to upstream, we really started to work upstream, and it's a learning curve. I mean you need to introduce people to the thought that there is a community of people you can go to, and you don't have individual contacts. I mean, if things go wrong and you need really urgent help, you still have the opportunity to get in touch with a single person, and they are all very kind, they offer remote desktop sessions to go with you through the code, and I mean that's not being ruled out, but the general rule is go to IRC, you have 20 people looking to your question, and eventually one will answer it. You really want to get engaged and work with those people and kind of show that you have some knowledge and you're actually trying, and the way you phrase your questions as opposed to like demanding something from them, they really don't need to give you anything, so you really got to think of them as, they're people, they're not your vendor, they're not someone you're giving money to where you can demand anything, you really got to work with them like friends and really try to engage and show that you're trying. A lot of the time, just showing that you're trying, even if you don't get it, people are so much more willing to work with you just that you just want to get in there, you want to learn and you're taking feedback positively and you're giving back positively, that makes a huge difference. And at the end of the day, I mean, you can really tell that you did a decent job if you're invited for reviews for totally different projects. I mean, this is really giving you some very positive feedback when people are adding you to the reviewer list. Yeah. Absolutely. So we've covered most of this in the conversation, but so what we get out of this is everybody has a benefit, right? Like the community gets new code, gets new functionality that's interesting and beneficial to them. Juniper gets additional people to look at their code and provide recommendations and possible bug fixes and or whatever. And we both get a solution, or actually all of us get a solution that provides additional functionality or for our customers. So as we said in the beginning, it's an open forum. We're interested in hearing your questions and your thoughts, be it on this or on any of our random. Okay, I have a good question. So partnership is a good thing. I mean, I've been part of this and it's been really great working with you guys. How do you, when there are multiple parties in one, like we have a customer, we have partners and all this, how do you make sure the customer sees a smooth experience that people are working together? They're not hacking, but actually integrating and stuff like that. Any suggestions on what's the right way to jointly develop so that the customer gets a smooth experience. The good question is community is messy, right? Community is humans, human relationships are messy. And sometimes people have arguments in public forums in the community and that's a healthy process. But I think part of it is educating customers about what you're seeing now is not unusual in the industry, it's just you're seeing it and normally you wouldn't. So I think that that's part of creating relationships and that's one of the things that Gil didn't say is one of the things that we bring to the table is we're in a lot of these communities and we can help you form those relationships. So maybe make a smoother experience, have less conflict coming into it because you understand the culture of these communities before you come in there and that helps. But I think part of it is also understanding that your customer is also going to be there, maybe not the sea level people that you're selling to, but the engineers that are also deploying and testing and using the code. And so it also gives us an opportunity and this is something we didn't talk about to have beyond the vendor relationship, it gives you an opportunity to have a much deeper, more technical relationship with the actual people who are going to be operating your code and production. Absolutely. I mean we see with some of our advanced customers that they're also contributing in these communities. So when they see us working together on something, they may make a recommendation based on, you know like these are use cases that we have so we'd like to see it work like this. But I know what you mean, there can be a lot of strife when customers see what seems like a hack but really is a workshop. Yeah, I had to slip that in, inside the inside jack. But I think communication is a big part of making that work is ensuring that customers are aware of sort of the different timelines for the functionality that they're looking for if they're looking for future functionality in a solution that we're working on together. Making sure that they're aware of the timelines, making sure that they're aware of the different features that we're working on and the progress of that. But some customers don't care about any of that, right? Some customers just want a product at the end of the thing, at the end of the day. And they don't want to hear about how the community is doing and how they're helping us. And in that case, we're happy to work with them in the call it the old communication model or we tell them when we expect a release to happen and that it's progressing great and here's the beta. Since we have more time, I might as well ask another question. So with Red Hat, obviously all of our products open source, upstream first. Almost all. That's the target, right? Yeah. Now with Juniper, obviously open con trail is open source. Is there any difference in terms of how we at Red Hat do things versus open con trail in terms of maybe this is really a question more for Michael. Dave and the team kind of went through kind of the way the Red Hat does the upstream first. Is the Juniper open con trail similar? Well, I mean the biggest difference, I think we can point out when we compare open stack with open con trail, for example, because open stack is mainly community driven. Open con trail also has a community which is much smaller because it's a much more point solution, it's an SDN controller. Whereas open stack is much bigger. It's many projects. Many people looking into it. So right now the development of open con trail is mainly influenced by Juniper and by customer requests. Whereas everything which goes into upstream and open stack comes from people who are contributing code to it. And that's, I think, the biggest difference right now and yeah. I mean one of the things that myself and Red Hat as a partner person, I'm interested in helping our partners sort of enhance their communities and have more contributions from the outside and not just internal contributions. And contributions from Red Hat, right? I mean, if you go look at the open con trail, con trail Git repos, you'll see quite a few Red Hat people who have started to contribute code in there. I mean, in this case it's usually code related to integration. It's triple L code. It's triple L code. It's not going into the core product yet. But the idea is we all benefit, as we mentioned, from forming a community around these products. Just to add to that couple of quick things, Ali. So from how we are doing upstreaming versus downstreaming, it's pretty much standard practice like what Red Hat, what they talked about with the branching process, et cetera. And that's one. And the second thing is Randy talked today at the keynote about what our approach to open source and community development is and how we are going forward, going to make it a much more broader community and how we are going to facilitate that. So that's where we are actually looking to partners like Red Hat who have a lot of experience to help us get to that goal of making it a much more diverse and broader community. And I would point out that that's the norm for most projects that come from a company is that the company remains for quite some time at the dominant developer. Open source developer communities grow from user communities either because when you get enough users, all their vendors start to pay attention or because your users are also technical, become technical contributors to solve problems that they have themselves. So it's not by any means unusual. Yeah, I would say like I mean really at the end of the day larger projects typically exist and are being built for the purposes of being productized. So I mean that's not an uncommon thing. I mean even like that's what Red Hat does, that's what Juniper does, that's what lots of people do. So I mean when you have a project that was started by a particular company, it being the primary contributor like you said is really not an uncommon or even necessarily a bad thing. It is what it is. Maybe a bit naive question from me. One of your slides looks like Juniper and Red Hat are announcing their partnership. Does OpenContrail will OpenContrail make its way into Red Hat portfolio? I know you use it in Red Hat OpenStack already. Anything beyond it all. Could you give the details maybe on how this partnership will? Well I mean right now what you can do as you said OpenContrail is a pure open source product so you can go to OpenContrail.org or to the GitHub repositories. You can pull the code, you can package your RPMs, then you can use the triple O heat templates. We contributed and started deployment on let's say centers for example. But right now you have to do the packaging effort. You have to compile it. So right now Juniper does not provide RPMs and that's what DP was talking about just before we're Randy this morning in the keynote at the open source day announced that we are gonna realign a little bit on how we are handling contribution of let's say packets to make it easier to consume OpenContrail for users. And I will point out represent OPNFE. So there's Stuart Mackey is a Juniper engineer who is working in OPNFE to enable the integration of OpenContrail with multiple installers. And that would be where I would expect to see any integration work happen. I don't believe it's on the road map for the Apex project at this point for the Frady's release but that is not locked and loaded yet. So that will be where I would expect to see it happen. I mean that's again something we're pretty much customer driven. So customer request was to be well integrated with OSP10 and REL and that's what we have done now. So that integration has been done and now there is some time to contribute something back and then make it easier for the community to consume everything we have done for REL. I think that takes us to the end of our, unless you have a very quick question. Yeah, I was just gonna really just make a good comment until you ask about the partnership. So today we obviously have joined customers together. That wasn't really mentioned, you know, like Orange in the UK and a few customers together. So they get into Juniper Contrail and then they get the Red Hat OpenStack from Red Hat and the two products all work together. So that's the partnership we have right now outside of the open source conversation that you've heard here. So yeah, if we didn't answer your question or you didn't wanna ask it publicly, I'm sure we'll be around and that's it. So thank you very much. Thank you. Thank you.