 Alright then, come on in. Mohammed, I'm sure I'm going to kill your last name. That's okay. Benik... Benik Kazemi. Benik Kazemi. Okay, I was close. Is a senior research fellow at IBM Research, and he's going to be talking today about network abstractions at different layers of the stack, so we're going to hear a little bit more. I heard mention of Tosca and Heat, so stay tuned, and we'll run this one. We'll get started right away, as we're running over a little bit. Thank you very much. Alright, thanks Mohammed. Thanks for coming guys. I hope you are having a good time in Hong Kong. Excited to be here. So let's get started with the outline. I'm going to talk about network abstractions at different layers, and then focus on Neutron, the open stack networking, and look at the abstractions that are provided by Neutron. And then talk about what we are proposing and is being considered in this design summit, the next session called Policy Extension Framework. I will discuss that and show how more application-centric network policies could be used to express network requirements at higher layers, and then finish with a few conclusions. So as you all know, Neutron is the open stack networking project. And as such, higher layers consume networking resources through the API that Neutron provides. And lower layers of the stack realize these network abstractions. Before I talk about Neutron and abstractions that it provides, let's have a quick look at the abstractions at higher layers and lower layers and see how they relate to what Neutron does. So at the highest level, when you want to deploy an application, usually you are dealing with more application-centric types of abstractions. At that layer, people don't care about the exact network abstractions that are being used other than the functionality that is expected to be provided through those network abstractions. This is just a simple example of a three-tier application. You are all familiar. You define, you want to be able to define three tiers of application, web servers, business logic, and a backend database. And you want to say that when it comes to networking, you want to have your first tier connected to the internet. And probably you want to specify that you provide load balancing and firewall rules that govern the connectivity to the internet. And maybe you want to specify quality of service between two tiers that you have, second tier and third tier. So as you can see, this is the extent of networking abstractions that people are comfortable with at the application layer. On the other hand, at lower layers, abstractions, needless to say, are more network-centric. They are, for the most part, device-oriented, relates to switches and routers. They are topology-aware, talk about forwarding packets, establishing routes between endpoints. And there are a variety of different network controllers, STN controllers, and they all use different northbound APIs. But at the end of the day, these are the kind of vehicles that Neutron uses to realize its abstractions. Having looked at these very quickly, now let's focus on Neutron. The OpenStack networking started as the quantum project and with the idea that it will provide minimal API, a minimum set of abstractions that you need to realize your networking needs. There are three major resources in the Neutron API. Networks are essentially an isolated layer-to-broadcast domains. They can be private or shared. Subnets can be used to assign a block of IP addresses to these networks and possibly define additional properties such as having DHCP servers or DNS servers, associating gatebates with your network, and so on and so forth. And finally, ports are essentially what are used to connect your virtual machines to the network. And there are essentially virtual switch ports. And they can have MAC addresses and IP addresses. And as Neutron was designed and developed, it was designed to be extendable and needless to say, it has been expanding through the last several cycles. Now, in addition to the basic abstractions, we have the abstractions that help with physical networks, things like provider network abstractions, and now in this release with multi-provider network extension, we have extensions for dealing with Layer 3 networking, routers, network address translation, floating IPs. Now we can specify those through the Neutron extensions. And there has been a lot of work being done in terms of specifying various services. Firewall as a service, load balancing as a service, and this has been the focus of the community in the last cycle, and it is a continuous work in progress. So if we want to express our three tier application using the abstractions that are available to us through Neutron today, one possible way of implementing it would be using an architecture similar to this. Use a single router, so you have to specify a router, and define three networks with associated subnets. Connect the networks into the router, specify ports that gets your visual machines connected to your network, and then possibly define a load balancer and firewall rules that govern the connectivity between different tiers of your application, and possibly through some of the plugins with some extensions you are capable of specifying quality of service at certain levels. And then finally you can connect your network to the external network. So this is kind of the one approach that you can use to express what you needed at the application layer. As you look at just a portion of the three tier application that we discussed, this is just the last tier, the web server. I have listed here the commands that you can use to realize it. And I have not included the commands for setting up the firewall or the load balancer or security groups or anything like that. These are just the basic connectivity instructions that you need to use to establish the connectivity between your external network and your web tier. So the point here is that as you can see through these command lines you have to create a network, you have to create a subnet, you have to create a router. For your subnets you assign IP addresses and all that. As you can see whatever you are doing is very network centric. So as an application layer person you really don't want to worry about creating a router and creating a network that gets hooked to that router. You just want to have a higher level kind of abstraction. So that's essentially the problem that we are trying to address here. We want to overcome the fact that the neutron abstractions are right now very close to physical devices. And we want to propose a higher level of abstraction. The policy extension framework adds more application centric abstraction to Neutron. This is the work that is being done by IBM and Cisco through a blueprint that is going to be discussed in the design summit this Friday. And it looks like that finally we are having enough amount of support from a wide group of participants to push this forward. So the idea is that let us extend Neutron by adding a couple of new abstractions. One is the connectivity group which is a grouping of endpoints and the other is policy which specifies the network functions governing connectivity between these groups. We want to do this in a way that is complementary to what is already there in Neutron. So we are not proposing abandoning what Neutron is doing. This is just to extend the abstraction that Neutron has to have a more application centric abstraction at the same time. So you may hear different names for the same proposal. Policy extension framework was the name that we usually started using and we got together with others in particular connectivity group extension API which was being proposed and the overall name of the proposal right now is group-based policy abstractions but you may see different names depending on what program you look at or you look at the blueprint. So they are all referring to the same kind of idea, exactly the same idea. So let's have a closer look. Groups are really nothing but a logical grouping of endpoints, virtual machines. They can have traditional MAC addresses and IP addresses each of these endpoints. The endpoints could be Neutron networks. So grouping is just groups provide the connectivity group provides a grouping of these resources. And policy essentially establishes the network function that governs the communication between these two connectivity groups. That's all. So for a policy you specify a source and a destination connectivity group and you say you specify the way you want to the connectivity be established. So we are going to look at this more carefully shortly. And just to make things easier in terms of development we have policy rules and policy sets. These are essentially just conveniences that makes things get implemented more easily. Policies are made of policy rules and a set of policies create a policy set. So the idea is that you can have multiple policy rules and put them together to create a policy. And at the application level you can specify a set of policies and call them a policy set like an application pattern just as a matter of making things more structured and understandable. So this is the hierarchy that is being proposed. Policy sets are made of policies and policies are essentially made of connectivity groups, source and destination if you will, and a set of rules. And these are policy rules that are essentially saying that perform a particular action on a class of traffic between these connectivity groups. So what are these different types of actions? We are talking about basic connectivity, maybe some access control, some more advanced features which include one or more services, service training, use of neutron services, firewall as a service, load balancer as a service, or even third party services that are available. Quality of service and monitoring that goes with it. These are the types of things that you can specify as part of your policy rule and therefore policy. And logical middle boxes. So let's have a look at the problem or three tier application again. This is again just one part of the three tier application, the web server tier connecting to the external network through firewall and a load balancer. So now that can be expressed by creating a connectivity group, a couple of them, one being external, connecting to the external networks, and then by creating a policy rule and policy. So the idea is that after you create your connectivity group you specify that you want to have a policy rule that only applies on the traffic that uses HTTP or HTTPS. That's the network traffic classifier that you are using. And then you are saying that you want to apply these two middle boxes. And how these middle boxes are instantiated or configured is beyond what we are addressing here but we are going to discuss. We are essentially that during the design summit session we are saying that somehow you have an identifier that refers to a service, a middle box that you are instantiating or somebody has instantiated. Possibly you can pass some configuration to that middle box but that's the extent of things you are doing. So we are using fewer instructions to set up our application but the point is that the kind of instructions or commands that we are using are substantially different now. It's not just that you are using less number of commands but you are talking about connectivity groups and policy rules and policies. This is a different level of abstraction as opposed to creating networks, creating routers, establishing a port on a router. So we are kind of saying that at the application layer this is much more natural for anybody who is not a networking expert to use an abstraction like that and then let's leave the realization of these abstractions to Neutron. That's the main point of using these new set of abstractions. So it says that what you do with the traffic that you are specifying here, we are here saying that just we want to allow the connectivity through a particular type of network traffic, anything that is HTTP or HTTPS is accepted and for that kind of traffic we are going to go through a service chain which includes a firewall and a load balancer. So we are essentially trying to do what is being shown here. We want to allow the traffic between the external networks and our web server here but we want the traffic to go through a firewall and a load balancer. Yeah. So those could be realized through different policy rules. So the way that it is organized right now and this can be evolved during the design sessions and discussions is that for each policy rule you specify a traffic classifier. And for that particular type of traffic you specify what you want to do with them. So you could have multiple policy rules that apply to the same kind of traffic or different types of traffic. So there are essentially what you have to deal with is the type of actions that you can provide, right? We are talking about simple connectivity and ACLs and middle boxes but we are also talking about quality of service monitoring. I will show a couple of examples that kind of make the usage a little bit more interesting and richer that we are going to discuss shortly. So that's the extent of the extension that is being discussed right now. Absolutely. That would be excellent to discuss. Yeah. We are proposing and getting ready to add these abstractions to Neutron as is. So let's look at the complete three-tier application again. This is the same three-tier applications. We have a connectivity group called Web here, a logic connectivity group, connectivity group database, another connectivity group, a special internet connectivity group and the middle boxes. And then the policy that is being specified here except this one didn't have enough space for a policy name but that's also another simple connectivity policy here. So if you say that you are adding these kind of abstractions at Neutron layer, how you consume it at higher layer becomes a question and one place to consume these new abstractions would be through heat. And this is a heat template. This is a sketch that says this is working towards implement using the abstractions that now this extension is providing at heat layer. You specify your connectivity groups. You specify a policy rule here that applies to a particular type of traffic and you specify service chain in this particular example. And then you tie everything together through this policy. Again, this is a sketch. If these extensions are added to Neutron, there will be resources that could be easily consumed at the heat and you can create these resources. We are discussing how what exactly endpoints are realized. For the most part, we want to have the endpoints, the ports and networks that are already defined in Neutron. Another option would be having endpoints, a resource of its own. So the decisions that are made in defining endpoints and how they are essentially whether they are first class objects or not would require that somehow somebody declares or defines the networks that are going to be used to create those endpoints on. So you can essentially have that as part of your service chain. Whether it is a router or a firewall or a load balancer is left to you, this provides the connectivity and directing the traffic between your connectivity groups through those virtual machines, which are your virtual appliances. So how you instantiate those virtual appliances you are addressing right here in this proposal. We are saying that we are able to refer to a resource that is already existing and somebody has created. So that's another problem. That's another thing that you have to discuss, how these visual appliances are created. There are a large number of people who are focused on service chaining and service instantiation. So load balancer as a service, for example, is trying to provide a generic way of specifying one kind of appliance. Some people who create load balancers don't like that kind of abstractions and that's why we are saying that you could use abstractions that are available at Neutron or you could refer to a third party kind of appliance, which is a visual appliance. So we are trying to keep that part as generic as possible. Yeah. Okay. Yeah. So that's the whole idea. So you have to specify some of this information as your configuration, but you don't need to specify anything about the router, having a router. Whether it is a router or a switch or anything else is irrelevant for what you want, you want the connectivity. No, this is a generic extension to, again, this is a proposal. It's going to be discussed in this summit, in particular on Friday, 3.10. I think I'm going to refer to that. Please join in that discussion. So this is a generic framework for adding policy as a new type of abstraction to Neutron. Yes, we are not showing it here. Yes, absolutely. So we are essentially saying that this is an identifier for that firewall and an identifier for a load balancer. Yes. Yes. How are you? Yes, exactly. So this could be, I mean, you can think of doing these things even outside. Yeah, go ahead. So this is essentially adding to the resources that Neutron has such that a heat template could use those. So we are essentially adding new resources to Neutron. And we are saying here that this is how possibly a heat template could take advantage of having those resources. That's all. As one of the higher layers that could utilize this heat is a candidate. Yes, absolutely. And the idea is that let's get away from more device-centric view of networking where we don't really need to focus on devices and just focus on the type of things that we want to do, the network functionality we want to provide as we move on along. So the question becomes whether, so right now the way heat operates, you can essentially use it as a main vehicle for infrastructure orchestration. You can instantiate resources that, let's say, NOVA, Cinder, or Neutron provide. For what we are saying, you need something at a higher level, which is a software orchestration that could be part of heat. I believe there is discussion among the heat community about extending heat to heat engine to make it something beyond the infrastructure orchestration. Other layers, other specifications such as Tosca could be used on top of what heat does right now to fully utilize these new abstractions. These are possibilities that need to be worked out. So let's look at a couple of examples. So we are saying that let's have these basic abstractions in place and let's see what things we can do. There are a variety of things that you could do if you had this policy extension. I'm just going to go through a few examples. So you could have your connectivity group modified such that a new VM is added to it. And that update to the connectivity group could be transferred to all the policies that are associated with that connectivity group. So as you add a new VM to your web tier because of higher load that you are experiencing, the load balancer as part of your service chain that is added to the policy here get notified and if semantically that load balancer is supposed to direct the traffic to all members of that tier that can be done automatically as a result of updating the connectivity group. That's one example. You can have logical middle boxes. When you specify, for example, monitoring a policy between two tiers, that could be used as collecting statistics on networking resources, mainly aggregating them at policy level, application level, and this could lead to a more comprehensive closed loop kind of processing. So the standard monitor, analyze, plan, and execute could be extended to use networking resources more easily. This is the standard way of having a closed loop where application specifies the service level that they require. They also publish the service level that they are experiencing. Now, if the service level that is required is not being met, you can react to it. And if the problem is the networking, that could lead to changes in your networking, providing higher bandwidth reservation for your applications or changing routes, or indirectly it could lead to changes in your networks. If during the analyze phase of your closed loop, you realize that you need to instantiate more VMs to act as your web server that could lead to changes to your load balancer such that your load balancer is aware of the new VM and can direct the traffic to it. Network controllers provide a lot of information about the topology, the underlying topology, but they are mainly dependent on physical topology. We are saying that you could use those kind of information resources and specify policies that relate to topology at the higher layer. You can talk about co-location and anti-co-location for network routes, possibly. You can specify, again, as part of your policy rules, asymmetric routes for forward and backward paths between two connectivity groups. You could specify hop counts if that's what you want to do. As you can see now, you are using the topology that is available at network controller level, and it's very network-centric at the higher layer of abstraction that doesn't say anything directly about the physical topology of your network. Most of the discussions that we have had has been limited to having the policies belonging to a single tenant. If we establish this framework, we can start talking about policies that govern connectivity between different tenants. That's where you can provide services that can be consumed by other tenants, or other users. The users could be outside your open stack infrastructure, coming out from external network, internet, or could be possibly another tenant. As you do that, you have to establish the connectivity across tenants, whether you do it in a net tenant-centric way or you require an admin-based approach. Again, those are the things that need to be worked out. Again, you could extend this policy abstraction to multiple tenants. To conclude, I talked about the fact that at different layers of stack, you may need to use a different type of abstraction. We are saying that we are proposing to add more application-centric type of abstraction to Neutron. This framework is going to be discussed on Friday. No. 8 at 3.10. The connectivity group extension, you could see group-based policy abstraction, is where we are going to try to start talking about the details or where we can go and how we can start implementing some of these features. We are all invited to attend that session as well. With that, if there are any questions? Yes? Sorry. My question is about the policy enforcement. After you define the policy and actions, let's say you take example as firewall route, the load balancer, what's your plan of enforcing those policies? In particular, you have multiple tiers. How are you going to make sure that in one place you can enforce all the policy across three different tiers? So the way that things are organized essentially in Neutron that is going to implement the policy is responsible for realizing that policy. So that's where you have to establish the network connectivity the way that the policy requires. So there is an implementation behind the policy that realizes it. I don't know if that addresses your concern or not. Probably not so much. I think I used your example for example. You add a new server into a web pool, right? And obviously whatever policy you define for that pool need to be propagated to the server. But I mean, if you have some other policy like a web server need to talk to a back-end server, how are you going to make sure the back-ends also be able to accept a new web server you just add into the pool? So again, these are the details that should be worked out. But we are saying that as resources get updated, connectivity groups get updated, all the policies that are connected to that particular connectivity group gets informed. Again, this is a proposal. That's a possibility. And through that you can enforce whatever is required. Why are you doing it? Because you're trying for some other... Yes, absolutely. We have to have a discussion about that. This is essentially just to get the ball rolling, extending what we have and providing the basic infrastructure for adding more stuff. Yeah, let's discuss. So software defined network controllers are essentially at the end of the day. If you are using an SDN controller is where you realize all these. So the discussion is what is the northbound SDN API that is being worked out if that turns out to be neutron as some suggest. This would be a perfect way of propagating those higher layer of abstractions to your controller. And I think I try to also show that how some of the things that those SDN controllers can do can be kind of exposed to higher layers as well. Thank you very much. And we'll be back at 2 o'clock in the same room, I believe. But it's lunchtime now.