 All right. Welcome to the network policy talk. My name is Mohamed, and I'm with Sumit Neksetem, and Stephen Wong, and Hemant Ravi here. We are going to do this presentation as a group. There are a bunch of people who have been involved in this work that we are going to mention during our talk. So if you guys recall, we had a discussion in the last summit where we started talking about network policy and how useful they can be. Since that talk, we have had an active subgroup in Neutron, and we have been actively working, and we have made significant progress during this cycle, and we are excited to share that with you guys today. So let's get started. I'm going to have a brief introduction just to motivate what we want to do, where we want to go, and then just to make sure that we are at the level set, talk about the Neutron abstractions very briefly and then start presenting the group policy extension. That's the work we have done. And then we have a proof of concept implementation that we are going to discuss in this talk and present a demo. And then with future directions for the work, and hopefully we will have enough time to have a lively debate at the end. I guess I could use this. So as you guys have, I'm sure have used that have experienced using Neutron, and sure you have noticed that the abstractions and the API that is provided by Neutron is for the most part network centric, and we have been advocating for a more application centric set of abstractions in addition to what Neutron is offering right now in terms of network abstractions. And the main goal is having a set of APIs or abstractions that are more easily consumable by application employers and non-networking admins. And as we set up to do this work, we wanted to make sure that we have a complete framework for having support for declarative models in which users can declare their intent with respect to network virtualization requirements that they have and get it as a result. We want to also make sure that we provide for separation of concerns such that different people with different roles in the cloud can apply the policies that they want to independently. So just to expand on that and be a bit more explicit about the things that we wanted to develop, we wanted to have a policy-based connectivity between different application tiers. That's essentially at the simplest form, we wanted to have an abstraction through which the application employer could say, I have an application tier, I have a web tier, and I just want them to be connected to each other and probably define some rules and policies with respect to how that connectivity is governed. In addition, we wanted to be able to declare, define and deploy these policies once and get them dynamically applied whenever applicable as new nodes join the web tier for whatever reason. The same policy that was applied to the web tier would get applied to the new entity, the new VM, the new endpoint. And as you guys probably have seen or have experienced, there is a good amount of work being done in Neutron in terms of defining various types of advanced services. So we want to make sure that we are able to take advantage of that work as different type of services such as load balancers and firewalls and VPNs are being developed. We want to be able to use those services and define our policies such that we can deploy, use those kind of services. And last, we wanted to have a clean way of, as I said, separation of concerns where administrators can define policies and those policies could get applied automatically to certain user networks without the user needing to do anything specific. Similarly, we wanted the user to be able to pick and choose policies that are being provided by other users in the system, administrators or application deployers. So these are the kind of things we wanted to do. And in order to get there, we thought this group policy extension is a very good model for getting us there. So we are going to talk about group policy extension and how we have modeled this new extension to Neutron. But before we get to that, I just want to have a couple of slides on the basic Neutron API. So we are on the same page. This is what Neutron provides right now. And the basic resources in Neutron are defined as networks, subnets, ports and routers to name just a few very important ones. As you can see, this is very much network-centric and it is for good reasons and it has been used for deploying various types of networks right now. Networks are isolated later to broadcast domains practically. You have the option of having private and shared networks. Similarly, subnets are a collection of a set of IP addresses that you can associate with your network and have possibly DNS servers or DHCP servers associated with your subnet. And ports where for most practical purposes, where your VMs get connected to your networks, this is just a logical representation of that. And routers, if you have different types of subnets in your system, you can kind of hook them up together. As you can see, we are kind of using a model which is very network-centric close to what we have in real world in some sense and trying to kind of virtualize or abstract that we have those network devices. So just to make this a little bit more concrete, you are looking at a simple three-tier application where we have a VIP tier, an application tier and a database tier. And we are saying that we have a certain type of connectivity between these tiers. There is external network also that we want to be connected to. And for example, just to demonstrate how things are, we want to have a firewall and a load balancer between the external network and our web tier, for example. Or we want to specify a certain quality of service requirement between our app tier and the database tier to make sure that we can provide a certain level of service, perhaps. So if you want to do this, and we can do it today, we have to essentially build a logical representation similar to what we have here, where we have different networks and subnets for each of our tiers and connect them to a router. So there is connectivity being established between different tiers and possibly to the external network. And then add our different services such as firewalls or load balancers to appropriate places like the router or anywhere else. So to do this, you essentially the list of commands that you should start executing, whether it is directly through the command line or through a heat template. At the end of the day, you have to create a network, create a subnet and assign possibly a range of IP addresses to it, and then connect your and create a router for connecting your different subnets and hook up your subnets to this router. So the point is not the number of commands you need to use to get this virtual network going, it's the kind of constructs that you're using, creating networks, subnets, routers, which make perfect sense for a lot of people, network admins, but as we have been saying, maybe not the best choice for certain other types of users, application deployers. And with that, I'm going to hand the mic to Sumit to talk about the group policy extensions. Thanks, Mohammad. Yeah, nice introduction and motivation to why we're doing this. So like you pointed out, there are elemental abstractions, network-centric abstractions which exist in Neutron, but what we're trying to do in OpenStack is deploy apps, right? And it's really not very easy for that app deployer or the app developer to be able to exercise these, so to say, lower-level network-centric abstractions, right? And it's not the point that you have to do it once. You have to be intimately familiar with what plugs in where to actually maintain the consistency of the system if anything goes wrong, right? So in order to address that, we are proposing the group policy model, which, if you're familiar with how the resources are represented in Neutron, is actually in the form of an extension. So it's optional to begin with, and it's meant to be very complementary to the existing sort of elemental Neutron network-centric model, right? I want to emphasize that it's complementary to what is out there today. It's not meant to be a rip and replace at all. So that said, right? The basic idea can essentially be boiled down to this slide, which is from an app deployer's perspective, right? You have your app deployed on your VMs or bare-metal hosts, right? You know how to stand up that app, and you think of that app or the entities which host that app as your endpoints. And for a collection of those endpoints, you should be able to group them together and apply policies on those, right? To be able to specify how those endpoints connect, or how those groups connect with each other, right? Based on network policies. So we have endpoints, collection of those endpoints, endpoints of the endpoint groups. And then the policy gets applied or expressed through something called as a contract, right? Why a contract? Because API contracts, you know, is kind of a known notion or a paradigm in the application world, right? So we thought that that's very easy for app deployers to understand. So a contract encapsulates a collection of policy rules or network policies, right? So just to reiterate, the whole model is obviously app deployer focused. You have endpoint groups and you have contracts, right? And what do you do with those? An endpoint group may say that I'm providing a particular contract by which, you know, if you are an endpoint group which embodies a web server, you would say that I essentially provide a web server contract, right? And then on the client side, the set of entities which comprise the client would say I consume this web contract, right? Note that there is an element of dynamic binding here. The notion of a contract is more like a template which captures the network policies, which can be reused. There might be one or more endpoint groups which actually provide that service, right? And it's left to the implementation as to how to match a particular contract to a candidate endpoint group provider, right? So you as a user do not have to manage that as to which endpoint you are consuming, right? And you don't have to maintain that connectivity relationship through the lifecycle of that entire, you know, interaction, as you would have to if you were purely using the network-centric layer of abstractions. So diving a little bit deeper, right? We mentioned the contract has policy rules. What does those policy rules look like? You have classifiers and actions, right? And the classifiers are actually very application-centric, right? You define, as an app deployer, you know at what layer 4 port your application is available at, right? So you define the port, you define the protocol, and you define the direction in which the communication needs to be permitted, right? Now based on the classifier, you have a set of actions that you can act on on traffic which meets this criteria, right? And we've enumerated a few of them in the first iteration of the demo that we'll show you. We actually implemented allow and redirect, again, based on the existing neutron constructs that are available today. And then we could further extend, you know, to quality of service, log, copy, mark, and this is an extensible list, right, based on what your infrastructure supports. So by the way, this is a whitelist based model, so you don't see an explicit deny action over there, right? Which is in sync with what OpenStack and Neutron has, right? You have to explicitly open communications up. So let's walk through the workflow, right? One step at a time. Probably best explained through a CLI. So you first create a classifier. Assuming in this case, the example is that there is a contract that you need to create to provide access to a web server, right? So the name of the classifier is insecure web access. You're trying to open up port 80 using TCP. The next thing that you do is you wrap that classifier into a policy rule and say that the action is allowed for this particular traffic. The third thing that you do is you create a contract out of this, right? And this is a very simplified example where we have just one policy rule in here, but you could have multiple of these, right? So this is a contract for allowing access to, allowing connectivity to a web server, right? And now you create and populate your endpoints and endpoint groups to actually access the web server which will be providing this contract, right? So you first create an endpoint group for a web server and you say that provides this web server contract which was created earlier. And then you stand up your application inside that web server EPG. So you explicitly create the endpoints in that. And then you have the consumer EPG which you define as the outside EPG. You allow connectivity to your web server from the outside world, right? So you say consumes contract web server contract. So that's it. That's all you need to signal as an intent from an app deployer's perspective to be able to allow this entire communication to happen, right? Everything else is sort of handled under the hood in a way that the system has a way to keep itself consistent, right? Something goes wrong. There might be multiple EPGs which are providing the same web server contract so you could fail over potentially. But you as an app deployer do not have to manage that, right? So trying to map to the earlier use case that Mohammed had brought up. This is the same three tier well-known use case and how that would look in terms of the constructs that we just talked about, right? So at each of the layers you see that there are contracts C1, C2, C3. And this is kind of an over simplified example. But you will see that for access from the outside world to the web server tier, we are opening up port 80. But then the action is to redirect through a firewall and a load balancer chain, right? Before it eventually hits the web server tier. So the claim is that's all that you need to do in terms of having to express intent, right? For the connectivity that you want to achieve. And so on for the access between the web tier and the app tier, the access between the app tier and the DB tier, right? That said, what was presented here was up until this point was the most basic form of the model. There are lots of knobs in here which are purely optional but which make the model a lot more richer. So there is a provision for defining scopes in terms of when you have multiple candidate EPGs providing a contract, how you can match the provider with the consumer. There are ways that there are things modeled in here which will allow you to essentially have one big contract but be able to define subsets of it rather than having to deal with many tiny contracts so that these contracts can be reused. We have a notion of a contract hierarchy. So the separation of concerns that Mohammed was talking about earlier, right? So you have an app guy and you have the infra guy, right? So an infra guy, let's say, wants to introduce some constraints on a communication that's already happening between two tiers, right? You want to introduce an IDS. So the contract hierarchy is a means to do that, right? And then we have the notion of labels. So you can assign labels to endpoints, endpoint groups and then based on what labels you assign, automatically policies get triggered corresponding to those which have been defined in the contract, right? So you don't have to go and orchestrate these changes. You assign a label and boom, automatically things propagate from there. With that, let me hand over to Stephen for the fun part of the presentation. Well, thank you, Sumit, for being a thorough explanation of the model. So we actually, as a team, put together a proof-of-concept implementations and we're going to demo it to all of you guys. So to reiterate Sumit's point that this is actually complementary to the Neutron constructs, the demo, the PLC implementation actually renders all the policies constructs into native Neutron constructs. So that's the architecture. So we can actually configure this using CLI Heat or Horizon. Through Neutron, we render and the policy manager, which is actually newly developed for this project, would render everything down to either Neutron... Neutron, sorry. That was a great action set. So it would render down to native Neutron constructs, which is what we actually do on this demo. It can actually do any ODL drivers or any other things that actually plug into it right. And for something like this, it's actually, it's not done just by the four of us. It's cross-renders, a lot of us actually participated, all of us actually believe in this model and hopefully you will too. Not the heat one. So actually explaining the demo a little bit. And Sumit just said actually, so you as an app owner wants to deploy an app that is actually two tiers, a web tier and as well as a client, so it's an external basically. So when the app people created all the constructs to enforce their policies down to the network, you would now see that the VM goes on to a client, a simulator client on the side and the web VM sitting on the other endpoint groups. You'll see all the policies get enforced and on the separation of control there, the admin would come in and actually add a firewall and you'll see that in this case they're saying maybe there's an attack on port 80, they want to actually start dropping packets on port 80. You'll see that now the client accessing the web tier using port 80 would no longer work. And then we're basically asking the app developers to start open a different port and you can see that it's basically just one line change to make it happen. So actually this is an explanation of what I just said. So the little browser is just moving around. And here we go. So the first thing to do is submit actually, show earlier too, is to create your classifiers. In this case you are basically creating classifiers to have bi-directional to all of them, no protocols. And now you're setting up the HTTP side. So you first set the classifiers, you have to associate that to any action set because that's actually the policy rules. So you set up HTTP as classifier also, as well as SSH because the SSL layer has to go through before HTTP as can actually go through. And now you create the action type, which is just allow as submit set. This is a wireless model. And now you associated the classifier with the action on the policy rules. And here you can see that we are separating out the actions from the classifier because we want reusability. Now you can actually all reuse the same actions. Even those three different classifiers going to three different policy rules, you are reusing the same actions. So now you're creating a contract based on the set of policy rules that we just set up. And then now you create an endpoint group that provides that contract. So this is the web tier. And then the client here, the external click tier would end point groups would now be consuming that particular contract. And then now you create an endpoint. You can see that now we're booting an image to be the web server. And then we are creating a client end points and associate that with the next boot, the novel boot of the client VM. So they're on two different end point groups. And the contract. So this is actually the admin contract that we talked about. So now you're creating a firewall policy which the admin would create on that example. Saying that right now we have an attack on port 80. The admin now wants to create a firewall that sits there and deny everything in port 80. So the admin's firewalls are created. And then we create actions that would actually redirect anything that matches the classifiers to now we route it to the firewall. And he creates a policy rules as before this is by admin. And now you create a policy rules that the admin actually wants to put the associated classifier with the action. And well for all three different protocol types. And now you created a contract, you updated a contract as you can see from horizon after typing in the admin password. That all your access on your demo which is your client and your tenant in this case now have the group policies set up. Contracts are all well set up. And this is a display of what we just set up actually on the classifiers and actions. And a set of endpoint groups on horizon. And you can see the topology. So on rendered down to neutral networks, you see that we actually created separate networks. The endpoint groups associated with the associated with the subnet. And we can we can actually even see the firewall being set up. Actually, I didn't pause here at the diagram. Sorry about that. Oh, sorry. Yeah. So tenant creates their policies for their web applications because only tenants or application owners know what kind of policy they want to apply to the applications. But then there's an infrastructure concern that can kick in, in which case the admin can create yet another policies to update the existing policies and then actually be applied to the app at that moment. So in any case, it's actually moving. So this is it. And that is that is a very good question. So we actually make it work at heat already. And Heyman is actually going to present to us in heat is actually much nicer looking, of course. I think the rest of the team have showed how cool group policies. The rest of the team have done a good job on showing how cool the group policies. Let's heat up the presentation with a little heat template, a hot template. So I mean, some of these, he basically we've integrated all the cons, all the resources group policy resources as a plugin into heat. And all of the power is available through the heat engine. The template here, if we put together, shows the same setup of defining an application and allowing a provider to provide that application and a consumer to consume that application. That's that's a base part. And one other nice aspect of the group policy resources is a level of hierarchy which lets an admin override some policies. So let me let me walk through some of the constructs here. So so the first the first part of the template has has a definition of the application, which which is essentially a contract. And to define a contract, you need some other elements such as classifiers and actions. And the contracts essentially define an application. And the endpoint groups are the people who consume the application. And the last part is the one the one that I was talking about where you can define another contract and override the action how this application is being consumed. So that's that I mean that shows a simplicity of the API needed to realize a complex topology like this. I mean it's it's basically abstracting the underlying things that need that need to be rendered to make this a reality. But for the application provider and the consumer and the focus is on the application and not not so much on the underlying topology that is needed to render the application. So I think the rest of the thing is a repeat of what happened when Stephen executed the CLI commands. The same thing the rest of the thing shows the things rendered. And the UI which was developed brings out the different aspects of different resources that were created. Both the group policy constructs as well as underlying network, networking constructs. So that's that's pretty much what I had. So wow. So yeah you can as you can see the topology is pretty much the same using a hit template. And for now, oh this is different thing. Because this is not really. You all know my son now. So the state of implementation is the proof and actually was already approved and reviewed. Obviously the POC is working. And then the POC branch you can actually access it from there. It's open. Everyone's welcome to look at the code if you're a hacker. The representation is still going in progress. There are obviously some complementary network service framework needs to be in place to actually do the much better job on the implementation. But it's actually pretty much almost there. For anyone who wants to actually know more, tomorrow we actually have a design session at 1050 in pretty much the same neutron room. The wiki page is on this URL and we welcome everyone to join our RSE meeting every week. Which is on Thursday. US time. So we can now open up for Q&A. Hi. I want to ask a question. So instead of for you to create network subnet and firewall and et cetera. If you use GPP directly then GPP will internally create a network subnet and firewall for you without using knowing of all the items. Right? Yes. Depends on who the user is. Okay. So if you just use GPP command line or from the GUI. So internally GPP will create a network of firewall and subnet for user. The user do not care about the... Exactly. Okay. Yeah. The resource atomicity is at the group policy model level. The fact that it orchestrates and creates underlying network resources is what we're trying to abstract the user away from. And that's the app deployer. Okay. But if you still want to know the details they can check it out. Okay. You just use the GUI or GUI. Yes. Okay. Standard GUI remains. So that would be create port, create network. They are all there. Okay. Is there just extension to that API? So what we showed in this and maybe you can bring up the slide again. So the group policy model is independent in itself. Right? But in the context of the current neutron you know network-centric abstractions we have a mapping to those abstractions as shown over here. Right? So the legacy policy driver here. Okay. Okay. So we've drawn a clean separation between the policy model and the existing neutron abstractions. Right? And what we've shown here is a way to do that. And if you use, if you configure your system with these drivers it's possible to essentially go and introspect and find out what networks, what ports, what subnets, what firewalls and so on. Okay. So you are not adding any of the new networking elements just a high-level abstraction. Right? Yes. Okay. Okay. Thank you. But that's one way of providing the mapping. Framework? So that's the work in progress. The ODL side is work in progress. Our model is very similar to what is the model in ODL. But we haven't done the mapping. We haven't, we don't have these drivers. The only one that we have in this proof of concept is the legacy. Okay. So the ODL model is somewhat different from the model that you have. Right? Yeah. Right. So is the intention to align it with the ODL? Okay. Yeah, the group-based policy model. Right. Yeah. Yeah. Right. So it is very similar. It is similar. It can be easily rendered into open daylight policy models, policy drivers. You have four minutes to go guys. Good. So when you generate the routers how do you pick these subnets and the external gateway addresses? So there are things that happens as a configuration. It can be set by the administrator or the pool of IP addresses that you have available and things like that. It happens orthogonal to what you do in terms of standing up those networks. So those things are part of just the, you know, neutron configuration? Yeah. Do you, do you intend to provide anything from your constructs? So that's what you have. Yeah, go ahead. Well just for example with subnet IP allocation and so forth, there's part of the policy model that you didn't really see here is called a routing domain that has kind of a supernet that's then divided up into subnets. So there's configuration that gets created implicitly if you don't, you know, if you don't do it yourself. Configuration is where the range of IPs to use for that will come from. But you can create it programmatically through the API as well and use whatever you want. Yeah. I'm Keshav. I don't know whether this question is right or not. So these, the endpoints and associated apps can be on different nodes and can it be across different VLAN also? The connectivity, right, whether it's VLANs, VXLANs, or whether there is multi-segment is an implementation or a mapping detail. I mean, is there any, I mean, in this one is there any, if apps are associated in different nodes or in different VLANs, the framework tries to take care of, I mean, creating those kind of networks and link them? The policy model is agnostic of that. Okay. Right. There are defined semantics for connectivity inside an endpoint group. Okay. Things inside an endpoint group have connectivity. So going from inside the endpoint group to the outside, you do not have. And then for, that's where you define the connectivity through the model. So ideally you only tell us what the behavior is supposed to be and then the network, the neutral legacy open data is going to set it up for you. So if it's across VLAN, it turns out to be segregation by VLAN, the network driver should take care of that. We have all the information on the Viki. Yeah. Links to the demo, links to our weekly meeting. If you have concerns, bring it to the meetings every week. Yeah, and we can obviously get out and have a discussion. The Viki. Thank you. That's okay. It's being destroyed.