 Welcome everyone. This panel is on the future of OpenStack Networking and I have a number of various distinguished guests here tonight to be talking about this or this afternoon. There are still a few seats up here in the front if you want to make yourself available. Yes. Okay, so as all of you know, because you're here obviously, that Neutron networking has been a major innovation that OpenStack has done in terms of separating out and probably the first time we've seen networking as a service created. So in many ways it may have been a rocky road as we've tried to sort of refactor Nova, take networking out into its own service but it follows a fundamental design principle that we have in OpenStack which is that we're designing a platform that's a set of loosely coupled but aligned services and so what we've really been doing in networking is taking that out so that we can really first of all foremost keep up with the changes that are happening in networking but then also really allow you people who are really the experts in networking to participate in something applying your own expertise. So with that I wanted to have the panelists actually introduce themselves first and then we've got a couple of questions and we will have, we have mics set up here as well so if you have questions you want to pose to the panel just walk up to the mic and I will recognize you and we can proceed. So Kyle why don't you start off? Hello, hi everyone. My name is Kyle Mestri. I work at Cisco and I'm the OpenStack Neutron PTL. I've been working on, this is actually my 7th OpenStack Summit so I've been involved with this for quite a while at this point. And my name is Dan Condi. I'm a director of products at Mitokora and we're a network virtualization company and this is my second OpenStack Summit. Hi, my name is Nils Smart. I work at a company called Plexi. We do data center network solutions, doing biz-devy things and what we really like are abstractions to drive our optical fabric. And one of the reasons to be here is abstractions and policy. Hi, I'm Chris Wright. I'm the technical director for software defined networking and network functions virtualization at Red Hat. I love networking. I'm excited about what Neutron could be and this is a great place to talk about that. So where I wanted to sort of start off the conversation was that it's not Neutron networking is actually a couple of years old so let's take stock of what we've done and particularly talk about some of the more recent changes that we've taken place in terms of the ML2 and how we've handled plugins. So who wants to take that off? Chris, you want to start on that? So Neutron reformally Quantum started off as a project whose goal was to provide a network abstraction to tenants to allocate and manage their network resources and as it started it was really just a set of APIs around a couple of plugins and at Red Hat we were looking at how are we actually going to take this and put it into production. One of the key things we saw was we work with our customers in very heterogeneous environments and having a single monolithic plugin was something that wasn't going to work well for our customers. So we started down a path of looking at how can we bring the ability to plug multiple different technologies into Neutron at one time with a project that ultimately became ML2 and now is a very core project to Neutron and what I think is really important about that, the lesson that I think is an important takeaway is where you can bring more and more core functionality into the core Neutron service and allow the plugins to be more like drivers that are really trying to do as little as possible. You get common code reuse, you get tested well understood code paths and initially when we started where something was really just a wrapper around a couple of different plugins it was not nearly as powerful as it is now. I could say that another interesting thing is it started off being just a layer 2 connectivity and I think the goal is to actually look forward and say that you want to add a lot more higher level services to allow people to have a much fuller experience in networking. You could have taken the argument and said let's just keep it at a lower level and be pure but I think the whole point is to just move forward as well. So I think having higher level functions and things like policy is very important so I think it's best to be forward looking and add more functionality and also as Chris said to add a lot of capabilities to add multiple vendors to collaborate in it as well. Yeah and I think the sort of to resonate what Dan just mentioned as a company that's basically started on the foundation of pretty much everyone else in the networking industry we looked at every neutron plugin out there and looked at you know should we implement the same type of mechanism to steer an entire infrastructure underneath or can we move the ball forward by taking a more abstract approach in looking at what what is necessary what is the intent of that infrastructure underneath and we started down a path inside of open daylight and now we're looking actively in neutron as well to figure out can we leverage a higher layer abstraction and use that to drive the infrastructure underneath rather than having to resort back to things we've known for 20 years so instead of going down to CLI or going to a net conf equivalent can we stay a little bit higher up so that we can take that intent compute paths around it and drive an infrastructure so I think that having this hybrid approach that Chris also mentioned is absolutely crucial because you cannot go from legacy infrastructure to new SDN infrastructure as one big bang and that kind of alludes as well to the challenges we have with with nova compute networking or nova networking and going and pulling that into net neutron so I think we'll learn a lot as we go along but abstractions are what we think is the world what brings the world around so so I think one of the things that that's worth mentioning as well and people alluded to it was the abstractions in neutron really allow for innovation from both vendors as well as open source plugins there's actually a talk right after this where we're going to discuss all of the different open source implementations that back the neutron apis as well so there's actually a lot of innovation going on in all areas here as well so actually Kyle I'd like to ask you since you're Kyle's newly elected a PTL now for this so moving forward we have a very diverse set of participants and contributors in in the community today a lot of issues have always been around there's not enough people to do reviews that were that it's taking too long to get changes in there how how are we going to address that this next year this coming year so that so that that's a really good question actually thanks for putting me on the spot there but so so I think what it comes down to ultimately is you have to you have to think of open stack as as a community and it was alluded to during the keynotes this morning as well so you know you you're going to get out of it what you put into it as well so what what I'd like to see is PTL is is is all of the new participants whether they're vendors or operators or whatever contributing back you know doing reviews getting involved with the project and things like that I think that's the best way that's the best way to get involved and that's the best way that we can help to scale it for the Juno development cycle and forward actually it'd be good to hear from other panelists again what are your own objectives for what you want to see accomplished in in this next time frame I have a comment I think it's really important to have the users being involved as well because admittedly there's a very strong vendor bias and how it was developed but if you look at things like Elbas a lot of the things that ultimately matter are how the users as tenants or people who manage a tenant understand and how to make the networking work for them now that doesn't mean that we want to ignore the infrastructure side as well which is equally important but I think having the balance for the end users as well as the infrastructure side is really critical looking at Neutron in the future. So actually that brings up a great point because Elbas is actually one of the areas where we've seen an influx of operators and users recently and it's actually been great to get a lot of a lot of that involvement because we're seeing things like use cases being set up and it's great to hear from people who are actually deploying this at scale like what they're what the pain points are what the challenges are and what they'd like to see going forward so it would be great to get that sort of involvement across the project in other areas as well. So what I would like to see happen over the next short period of time in in Neutron development is to make Neutron deployable just usable nothing complicated just make it scale make it robust make it functional because when we're talking to end users their biggest pain point is often in the networking deployment part of how do you set stand up a cloud. I think that that's an achievable goal it's really not too lofty to say let's focus on core stability and core functionality and while features are important and there are a few key features that I hear over and over again from talking to users you know I think I think it builds a nice prioritized list of where where can this development community put their focus and I really do think admitting that we need to focus on some core quality and and a user-centric point of view or operator-centric point of view is is a critical part of that. I can only add only add to that that the user side of it has long been under highlighted in a lot of ways in the networking industry. If you see the the current trend of sort of standardization bodies that used to have a lot of involvement from operators and from telecom companies that is dwindling a little bit so less people less end users there if there is one place where end users can show up again and have a meaningful voice I think it's on the open stack side so 100% agree and when you do that and when you bring your voice it often helps just to talk about what your intent is the fact that you've done something the same way for 20 years is valuable to know but really the the core behind the problem is what we often would like to understand what is it you're you're trying to achieve and with that we can hopefully build a better networking industry going forward. Okay so one of one of the questions that I do urge you in the audience go up to Mike's if you would like to ask your own question here is that as as open stack gains in popularity and becomes more and more widespread the number of use cases starts to multiply and so I actually think we are seeing very large you know distinctions between someone trying to do an enterprise cloud on-premise or whatever versus a telco that's that's interested in network function virtualization can we accommodate all that in one project such as Neutron or do we or do you anticipate seeing this break out into into several different areas to cover the different use cases. Yes No seriously my background is in Linux and if you look at what we've done in the in Linux where we have taken a group of developers who can are building the Linux kernel and operating system around that that scales from the phone in your pocket to running Wall Street exchanges to all the Fortune 1000 enterprise data centers it's not a stretch of the imagination in my opinion to see Neutron fitting into that same kind of profile for networking services in an open stack and it does start with some core sanity and the ability to listen to what users need to do and not be too far off on just pushing like a vendor driven initiative agenda but really listening to how users want to deploy and manage their networking portion of their infrastructure so I think it's 100 possible scale up scale down it we've seen it happen in other parts of the industry so I'm still optimistic that we can really make positive change with with Neutron. Yeah I'd like to think that infrastructures start to become more similar same way of deploying inside of AWS is now possible inside of enterprises network function virtualization the platform running all of that will be some form of a some form of a cloud service chain together and that same service chaining is necessary whether or not you run it locally or remotely so I think that the key thing to solve though one certainly stability but two it's easy to forget and I'll be a broken record here but it's easy to forget what the intent is of the infrastructure the intent is never complexity the intent is delivering something for the end user we've got to elevate that because otherwise we're going to be mired in in minutiae and CLI level details we really want to step up there right and I think the other thing about use cases is it's a way to keep honest right because it's so easy for a lot of people who are in the development side to say it looks like a very clean set of API's it looks it's everything is orthogonal and let's go with it but you really need to go and deal with use cases from the beginning so you have a good set a rich set of use cases that you want to always check your designs against so as long as you're really going back to the use cases from the beginning it's a good way to keep not only the the vendors happy but obviously the end users happy as well and the other important thing is for example make sure that's in your design process so that even when you're designing the blueprints and such to keep the use cases in mind so some of the work that we've been involved in like in a group policy project the use case documents were really done early on so I think that's a good way to go as well and and also going back to the case about NFV Neutron has continued to involve including service insertion and firewalls and such so there are some elements to NFV that are outside as the main but Neutron is evolving to create a really good foundation for NFV yeah I think it's worth it's worth pointing out that that there are differences in these things Lou like you had brought up however there's a lot of similarities as well I think we tend to focus on the differences between NFV between private cloud between public cloud but there it turns out there actually is a lot of overlap in these use cases as well I mean in the NFV case you need a platform to actually run the infrastructure components that you're launching so that's where something like OpenStack the broad OpenStack comes into play I think so yeah then I would only ask that I would basically as Pitello and for the rest of the contributors let's document those use cases we need more written material for our users to understand if what from what they're trying to do here's the path that they should be taking with Neutron we're expanding the possibilities here but we I think are very lagging behind in terms of the technical briefs white papers everything associated with how you actually then then deploy Neutron for a real objective here yeah we have a question here yeah produce yourself thank you my name is Anise shake I work at Google I had a question this is the future of OpenStack networking so one of the questions that came up at the last summit that was interesting is this question about how much function we actually put into OpenStack's networking stack versus keeping it as keeping OpenStack networking focused on APIs that expose capabilities and then really letting plugins and various backends provide the functionality so I didn't see that there was a lot of consensus last time I'm just wondering if you think that any you all being you know very involved in the project think that any consensus is emerging and where you think we ought to be going so go ahead so actually that that's a really good question I I think what you're going to see happening is you're going to see innovation happening on both angles for that so for instance you're going to see open source and proprietary controller platforms like open daylight or open contrail continue to innovate as well and you're going to see some abstractions move there you're going to see those things possibly implement things like service chaining or even L3 routing and things like that on the flip side you're also seeing innovation in the core Neutron plugins as well the ml2 plugin with the open v-switch and the linux bridge agents there's there's actually work going on in Juno to do distributed virtual router functionality there's also the folks working on the L2 population support are doing some great things with with overlay networking as well so I think the reality is you're going to see innovation in both of those areas going forward yeah this is not unfortunately it's not a revolution as a startup on on this panel here I'd like to see some of the traditional technologies kind of leave them at the area where they have to be but sort of newer green field portions of your data center that you're building out with a cloud infrastructure let's use sdn let's use group-based policy for that kind of stuff with the reality is you're going to have to support sort of a brown edge around that green field and that's unfortunately a reality the question is should we spend most of our time recreating what we already had in the past or should we move forward to more sort of policy driven orchestration down below and I would like to see more involvement on the policy side simply because we have already done all the other stuff 20 years ago and up to an ounce so I'd like to see more investment in the new but the reality is we're going to have to work on some of the old stuff as well yeah actually chris if you might address because I think all along what we've been trying to do is to have neutron be responsible for the abstractions and the abstractions that make sense then to a user calling the apis and then let implementations actually defer to a lower level or or anything else controllers and things like that are we able to maintain them as we move into services and integrating and stitching together services is it sufficient for us to remain just really at the abstraction level and defer the operational implementation to to plug-ins and drivers all right I mean it really depends on how we're defining these abstractions if we look at networking today we've started off with a very simple set of primitives which reflect historical views of networking and service insertion is the is sort of this beginning to try to tip in a slightly different direction but we're still tethered to we put the service in a particular spot in the network or in a particular path in the network and I've been concerned that in in the neutron side we're slowly building an sdn controller within neutron while at the same time sdn controllers are evolving outside of neutron and I think it would be really interesting to look at that and look at where there's value in in maintaining just the api and abstraction view within neutron and where there's value in trying to bring more core functionality into neutron and when I first was looking at quantum I felt like the right thing to do was put more and more core functionality into quantum as we've evolved and as the industry's evolved I've actually come around and I feel like there's there's more value in keeping high level abstractions I mean if you look at nova it's not really a hypervisor it doesn't even have some of the low level management infrastructure like libvert it's really maintaining the the higher level interfaces and then enough logic to make that coherent and sane and I I think we could do something similar in in neutron all right and I do want to add that I think innovation or work rather has to happen on both ends because obviously thank you wow I think you're not clapping for me right but anyhow where was I yeah innovation happens to happen on on both sides as well so there's also an issue of just parity with nova networking as well so that's kind of a sticky point as well where we have to get those things done has to be achieved that has to be achieved right so we can't look completely on the the high end I mean policy work is extremely important it's the way to innovate but let's also not forget about parity so that we could just move forward with the basics so so Jeff yeah so Jeff Arnold the Cisco cloud service is not the technology part the building a cloud part can I put a plea into all of the technology vendors here that we're working on contributing to networking and open stack don't forget the metrics the salameter metrics the alarms the all of the stuff which so far has been woefully inadequate and when it comes to people trying to build clouds and actually make money out of them by creating billing models and so forth right now we have nowhere near enough data do a good job so that's been a real that's a real gap right now in the in the in the the open stack networking and also in storage as well but don't please please more metrics more more more more visibility into the behavior of the system that raises a good so whose responsibility is that so when we say we want actually heat to be able to orchestrate networking or a salameter to be able is it really the responsibility of the neutron team to make those things happen or do we have to form the collaboration with the other projects I think that's an example of collaboration across the projects as well which is which is something that that is good I think it's healthy for the whole open stack ecosystem and we need to make sure that that the projects are are coordinating across for things like that because like Jeff was saying something like billing you know we need we need to make sure that that salameter is providing the right infrastructure and that we're utilizing that infrastructure to provide the right data so the operators can make money like Jeff said and I think this is one of those examples where networking traditionally was in a silo in more of the flexible infrastructures cloud infrastructures that siloization is going to move away those barriers are going to move away so almost naturally project teams here will have to work together to get that information out of networking so part of that is I guess also the willingness to go across that boundary meaning abstractions will have to give information back in a useful manner if if you can insert a high-level policy object that says create me this three tier network and the stats you're going to get back are still on a vlan on a port basis then you've basically done half the job if not less so there is a lot of work that still has to happen on that front I agree yeah and one more thing to add is when you're at a high level abstraction layer you sometimes forget the fact that the networking is still running on metal the real networks right so the question is if you want to understand better physical networking issues whether it's things like qos traffic steering how can that be properly dealt with and I think that's more of a area of vendor innovation as well it doesn't necessarily live at the 10th level but those things have to be addressed to really let the operators and the people who run the infrastructure infrastructure itself to understand how to provide a better service for the tenants next question here hi this is Ramkumar Gauri Shankar from Extreme Networks so I had a question about neutron scalability so I'm not sure Havana or Icehouse know how to move towards this concept of cells and to enable aggregation and scaling through you know multi-layer cells that report to each other and and build on top of it but I have not heard anything about neutron support for it or how neutron plugs into such an architecture whether it still runs at the top level and if so how does it scale or does it run at each individual node level in which case how do the apis get exposed and how do they interact with each other is that something that's going to be addressed in the future roadmap or is neutron scalability going to be addressed in a completely different way I could try something here so if you're talking about scalability it again is an area of vendor innovation itself I think neutron per se may not address that certainly the default implementations have a lot of I would say shortcomings in terms of single points of failure for example but like the product that we have Amidonet actually has a distributed architecture where you don't have a single point of failure because the equivalent of a controller doesn't exist so rather than a centralized controller the intelligence is distributed on each of the hosts so not only for us but there are a lot of other vendors who could enable that form of innovation at the vendor level so I think that's one way to do it so at and at the and at the neutron level one of the things that we're we're looking at possibly in Juno or beyond there's actually a design summit session around refactoring the neutron core and one of the things that we're that we're potentially looking at there is you know how can we make it so you can scale this by running multiple API servers for example behind just a normal load balancer and you can scale things that way right now we're using we're using a event lit for for threading inside there maybe it's possible we move to single threaded API servers and so there's discussions around things like this and I think that certainly this is something we'd like to try to address in the Juno time frame yeah sort of lastly I think just sheer networking scale we've got open daylight on one end trying to address some of that as well you know it's far from in my opinion it's far from actually being run in production so I'd say neutron is in a better state than than where the initial release of open daylight is but it certainly has a lot of the movement behind it so from a scale perspective I'm expecting a lot to also go amount of open daylight in terms of actual raw scale and ability to run virtual networks and interface with them I know there's going to be other other talks on this during the the summit here but people are now talking about policy driven ways of looking at networking so rather than having to have the user create a three-turn network and and stitch together these services they can express policy it might be good for us to on this panel just give some some view explain where that's coming from so that people start to get educated about what what the thinking is behind that so so I'll take a first crack at this so so I was I was actually on a panel last fall as well at Linux gone around this some of this and one of the interesting things is if you look at network controllers today what do they look like right they provide common abstractions for networking interfaces and if you ask yourself why it's because networking people design those so we're still talking about things like ports and subnets and routers and things like this so the the work you're alluding to I think is the group-based policy work which is going on in both open daylight and open stack where we're trying to to change the paradigm for application developers so they don't have to think in terms of common networking elements which they may not understand or may not want to understand and instead they can think of terms of connectivity and abstraction like that so I think we're trying to move things forward in in that direction by providing a new set of APIs I'd say right now we're in a situation where the the primitives that we're giving application developers are user hostile primitives you have to become a network engineer to deploy an application and that really makes no sense when the whole purpose here is to enable quick application deployments so the the focus of of group policy or or a higher level abstraction is to put the the application developer back in charge and really try to recognize the basic things that you're trying to do as an app developer is create connectivity between different portions of your application and it's really that simple and exposing that in network engineering terms makes sense to all the network engineers that are designing the system but it's just an impedance mismatch the actual users or developers trying to ride on top of this and I would say that it's just a natural evolution if you look at other parts in computer science people have always done things in a more like imperative way and databases you were in the old days people are looking at exactly in which tables to look at and in which field but eventually you had higher level query languages that sort of took people away to being more absent tricks so this is more of a natural evolution of any field and I think it really belongs in the evolution of networking as well. So just add sort of two things one a lot of what the network ought to do is already known outside of networking meaning if you deploy heat template you kind of already know what the relationship is so on one end there's a lot of stuff that we don't have to reimplement if we have a policy driven way and second it allows us to get the network out of the way. The information is partially there add a policy construct to it add the ride level of orchestration to it give those tools directly to the software developers and deploy it on your own private cloud in the same way as you would deploy it on A to S instances open shift you know you name it and it's it's that simple get out of the way and use the information that's already out there. Can someone give me examples of policies we that's a big term what practically what would be the kind of policies you think that would that an end user would care about and be able to express with us. First simple example this storage device or this cluster of storage nodes will have to interact with these sets of back end servers that relationship is being put in place already in other places give it some special treatment as simple as that and the fact that that employs VLANs and ports underneath and some level of path diversity some level of capacity management is kind of is automatically derived from that higher level policy that says there is a relationship and that can naturally evolve to slightly more complex things where this group of front ends exposes sets of web services I want to publish that those and have other people use that in the way I've defined it. Or it could even be things that are extremely system operator specific like even time of day between let's say 6 p.m. to 2 a.m. I want to have these policies applied because that's when backup is running or it's not running so you could really try to map policies into the way a system manager or even a DevOps person would think about so don't think in terms of what a network engineer or a network manager thinks about think in terms of what the tenant or the higher level management of the systems would think about how to apply their policies to the networks. Yeah I think that's exactly right where you have a multi-tiered application and one of the reasons that you do something like put one tier in one subnet and another tier in another subnet is not so much about subnetting and it's more about where you apply something like security policy so it creates a policy security policy boundary. If we can express that without going down to the granularity of ports and subnets we've made something that's more consumable for application developers which is again that's that's what we're trying to support here. And what's I think what's really exciting is the policy is not just here in Neutron or here in some of the projects but and also some of the other projects for for storage or for another project called Congress where they're taking a much broader look at hey what is my overarching policy across that infrastructure of both compute storage and applications you know minimum version for MySQL should be X. Those kinds of policies can be easily combined with with an infrastructure that supports being spoken to in policy. They're not necessarily the same but they ultimately boil down to or help us get to a point where in the abstract you can read okay this was the intent three tier application it's a dev environment and by the way these minimum corporate requirements have to be met. That's I believe the the fun thing that can go out we'll end up with. Great great great next question here. Hi my name is wow my name is John Bechie I'm from Bank of America and I'm interested about the silo part of it I came from a networking background right and then I moved into storage and did about six or seven years over there and now I've been doing cloud kind of things and when you talked about the silos I'm interested to know at what point like I don't want to build a three tier network I don't want to configure BGP anymore now I'm on the server side of the world when are you guys going to turn neutron over to me so I can just do my firewalls and my load balancing when I build servers you were talking about the server side I'm trying to figure out where it becomes a project that's in the network silo because frankly all the network people are in this room right all the server people are right next door so we're still hanging out in their silos I'd like to know what's going to happen there we're we're able to collaborate with you guys without again how do you I hope I phrase my question well I'm just trying to say how can I do the things that I want to do because there's a whole heck of a lot of stuff that you do that I don't care about anymore and where does that collaboration come together do you see I mean one of the issues we have is just the beginning build out of a deployment so how do you how do you bootstrap this whole system networking is key to that the the services need to talk to each other compute nodes need to be on specific networks and we you know we're looking at how can you do this with with modern tools so that you're thinking in terms of deploying a bare a bare metal rack start with start with nothing and bootstrap the whole system say you know populating control nodes in the right spot and turning on the network interfaces in the compute nodes that they show up on the right networks that's the beginning of sort of breaking down some of these silos and then as a as a user ideally we don't you know we're we're seeing these as compute storage network it's a set of api so we don't have that same siloed approach but on the on the infrastructure management operator side breaking down some of these barriers and having you know the the ability to bootstrap this system from scratch I think is starting to touch on that and you see you know differing vendors already have integrations with configuration management tools for their physical switching gear we can start to treat these things more more like servers already and use common infrastructure for managing the infrastructure whether it's a server box storage array networking switch I mean that to me is the really exciting part where we are actually moving forward and part of what I was trying to say is just that piece where you know where do you give over a subset of commands to the folks in the server world right I want you to have all your stuff and I don't I don't want to be able to mess up your bgp routes right or add any routers to or other external connections and other things you're going to be able to do with the tool yeah that's kind of where I so that that's actually an interesting point because this maybe gets to something that that we don't talk about much in the open stack world we we talk about the separation of tenants from from operators but I think what you're referring to now is the segregation of of the responsibilities on the operator side you may have a storage admin a network admin or a server admin or something is that that's kind of where you're headed and you want to make sure that those I build a server today and I can do certain things got lots of automation and things are really cool but it would really be nice to have all the rules in sdn to say who can talk to who right there's things like pc i out there that make that exciting and there's a lot of things going on that I need to be able to do things when I'm building servers that touch the network and there's kind of a wall there that I'm trying to get across well so I mean so you work for a bank so I'm sure you're thinking about a lot of regulatory compliance or some things that those are things that really drive you right not necessarily I'm just thinking about most servers if I think of my network I need a port I might need a load balance rule right I might need some firewalls right those are the three things as a server guy that I should be standing in the other room those are really the only three things I care about so I want to be able to make sure I can touch your stuff that's being built into the automation without stepping on your toes okay so I think actually if I want to move on from this point yeah I think that a lot of that was already there in that was the first sort of generation of neutron which was to be able to provide networks ports subnets and attached virtual machines through that programmatically through an api so that the the developers don't that is done for them by the by the neutron servers now what you're hearing actually is now we're saying let's go one step further what you're really trying to accomplish is capture the intent of this set of servers needs to talk to this set of servers under the following conditions and that's where I think it'd be interesting for you to sort of watch for the evolution now this policy driven approach where with that now you don't even developers don't even have to now worry about ports and networks instead they can talk about their intent but I wanted to get to the last question because we have only about three minutes left here so hi I'm Joe Harrison I'm from CERN going briefly back to the issue of scalability do you not think it's important instead of relying on vendors for this sort of thing for the scalability to actually make sure that there's a reference scalable open source implementation that's completely vendor agnostic for example we don't have a homogenous networking environment we can't just choose one networking vendor we don't have the budget for it so do you not think it's important that we implement things in such a way that it's scalable across vendors or even without any specific vendors no absolutely and that that was the point that I was making was that you know absolutely were that's the goal for Juno is to come up with a scalable open source reference implementation of Neutron that people can deploy at scale so so definitely that's you know as PTL that's that's one of the things that that we're going to accomplish during the Juno cycle and sort of just to add to that as a as a vendor that's music to my ears as well because as soon as the market says your scalable reference implementation for CERN is you know a 10 million of something then immediately it makes the budget discussions internally so much easier to say hey you know the open source thing can do X and ours does Y you know there's a delta we need to fix it so all for it Richard Stern with Walmart e-commerce a couple prior topics I think Neutron is still siloed in its intent and its approach in short there's a lot of stuff in the existing enterprise infrastructure not in the cloud that the cloud has to get to and talking about routing and subnetting and all that good stuff it fails primarily around padding and netting it doesn't scale at all I have tons of VMs that need to get to stuff in the enterprise outside the cloud and there's a total failure there it's a big disconnect so my point being there needs to be either a policy along with a core implementation that says for this class of traffic or servers whatever makes sense allow this to be optimized in Neutron to avoid the bottleneck of the address translation in essence padding or something that looks like pad and that's a core routing topic where it just falls flat so for example like one of the things that we've done was created a vx line gateway so that there's some workloads that cannot be virtualized for example or would not run within open stacks you want to make sure those workloads communicate well within the VMs within your open stack cloud is that what you're looking at or more for performance reasons as well very simple lots of apps that have to talk to databases right that are bare metal right that are not in the cloud right so all of these apps in the cloud have to initiate traffic to all of the middleware all of the databases so in the native implementation it has to go through the NAT layer which turns into a big choke point right there right let alone latency and the usual routing you know network stuff like that so it's a huge impediment and I'd argue that Neutron has put itself into a silo the I think let me characterize it I think that Neutron because it's about networking it's larger than open stack it has to be able to talk to things outside of open stack whereas if you look at a lot of the other projects within open stack it can be in within you know setting up the virtual machines just within the domain managed by open stack but networking has a special requirement that it has to be able to address connectivity to things that are outside of the what is being governed by open stack I think that's very well exactly is like an attitude issue right think of you're playing not just in the cloud where this is simple simple routing so on and so and all that but outside you're in a larger scope to your very point that's great unfortunately we've got to cut it off at this point so that you can get on to the other sections as well so thank you very much for attending and we'll see you at the rest of the conference