(Cross-posting to the operators list for feedback) Thank you Ihar for starting this up. In the absence of any kind of blog or other outlet of my own to disseminate this, let me share my plans here...
Routed Networks: My plans for Mitaka (and beyond) are around routed networks. During Liberty, I saw the request from operators in the form of an RFE [1] (one of the first in the new RFE process I think). The request resonated with me because I had been thinking of doing this since almost the day I started working on HP's cloud. We went on to define use cases around this to understand what operators are looking for [2]. It seemed to me like we were on the right track. I went to work and put up a spec which proposed using provider networks for each of the network segments. It used one more instance of a Network for the routed network and a sort of provider router which connected it to the provider Networks for the segments. This was a short cut and the community called me on it [3]. Despite some existing leakage of L3 in to the supposedly L2 only Network model, the community wants to keep Networks L2 only. This makes a lot of sense and I think we'll end up with a better long-term solution even if we need to go through a little more pain to get there. I've started a new proposal [4] which adds two new L3 constructs to the model. They are RoutedNetworkGroup and SubnetGroup. A RoutedNetworkGroup groups Networks. It represents a bunch of L2 segments that are mutually reachable via L3. In other words, there are a bunch of L2 networks, each with its own subnet(s). All of the subnets of the other networks are reachable through the default routes of each of the networks. We will be able to create ports using a group as a hint instead of specifying a Network explicitly. To accomplish this, the proposal adds a new mechanism to map hosts to Networks. In our mid-cycle, we talked through a flow where Neutron could filter host candidates given a group as a hint based on IP availability on the underlying Networks. Port creation would be passed the same group hint and a specific host to create a new port. My current understanding is that this will meet operators requirements to allow users to choose where to boot a VM based on the L3 network so that they don't have to be aware of the segments. I'm looking to get confirmation on this. I've spoken to Kris Lindgren about this and it seems promising. A SubnetGroup groups subnets. I don't think the Subnet model in Neutron does a good job of representing L3. First, floating ips connected to Network instead of Subnet, but floating ips are really an L3 thing! Second, an L3 network often has more than just one cidr. With ipv4 specifically, it is a collection of cidrs together that is important. The current model doesn't allow a group of subnets without a Network. The SubnetGroup object fills this gap. It groups Subnets; floating IPs will hang off of these instead of Networks; and they can be owned by Networks or RoutedNetworkGroups. One day, they will also stand alone to represent a pure L3-only network (e.g. Calico). This new model will allow Neutron routers to connect to an L3 network, host floating IPs from the L3 network, and even allow routing directly to tenant networks without NAT. BGP: The BGP work is being led by Ryan Tidwell and Vikram Choudhary and is discussed weekly in the L3 team meeting [5]. I plan to continue giving my full support to this effort as it aligns very nicely with the routed networks work. Connecting Neutron routers to an L3 network needs one more thing to work. The L3 network needs to know the next hop address for any routes behind them. This includes floating ips and tenant networks. This can be accomplished by injecting routes in to the routers, a dynamic routing protocol, proxy arp, or whatever else. The BGP work being done aims to fill this gap. In short, it turns Neutron in to a BGP speaker to the L3 network. Floating IPs: This is mostly future work. In Neutron today, a floating IP is an IP whose traffic goes to a Neutron router and is a 1-1 NAT to a private IP on the tenant network. I'd like to generalize this concept. For example, DNAT could be done per TCP/UDP port to different internal ports/addresses. Gal Sagie has posted a spec something like this [6]. Who says floating ips have to mean NAT? I've seen how one operator does floating ips by instructing the VM to accept the floating IP address as one of its own. We could also do NAT at the port on the compute host if the VM instance doesn't understand what to do with it. The point is, why does the router have to be involved, especially if we now have routed networks and BGP to work with? We could also route more than one address to an instance or even whole subnets. Floating subnets, heh. This might be useful for containers running inside of instances and I actually talked to a few people at LinuxCon who would like to see this happen. There is also the possibility of anycast floating ips. Who knows what else? Carl [1] https://bugs.launchpad.net/neutron/+bug/1458890 [2] https://etherpad.openstack.org/p/Network_Segmentation_Usecases [3] http://lists.openstack.org/pipermail/openstack-dev/2015-July/thread.html#70028 [4] https://review.openstack.org/#/c/225384/ [5] https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam [6] https://review.openstack.org/#/c/224727/ _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
