Open Stack

(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/