<div dir="ltr"><div><div><div>On my top of mind for Mitaka:<br><br><u><b>Introducing common Classifier Model [1]:<br></b></u>Currently, neutron service/s  (e.g. Service Function Chaining, QoS, Tap as a Service, FWaaS, Security Group etc) which requires traffic classification defines their own classifier 
model. This introduces redundancy. In order to address redundancy and easier code maintenance, we propose to have a common classifier resource in Neutron which can be leveraged by multiple services in turn.<br></div><div><br></div><u><b>Enhancing QoS functionality [2]:<br></b></u></div><div>It is great to have QoS framework merged to Neutron during last release cycle. Now it's the time to consolidate and make the existing QoS functionality richer by implementing few of the simple and important ideas listed below:<br></div><div>-> Support for Linux-Bridge driver. <b>[2a]</b><br></div><div>-> Adding VLAN priority tagging functionality.<b> [2b]</b><br></div><div>-> Adding ECN functionality. <b>[2c]</b><br></div><div><br></div><div><u><b>Enhancing BGP framework [3]:<br></b></u></div><div>Adding to Carl, I would also like to analyze<br>-> How we can merge ongoing projects like BGPVPN <b>[3a]</b> and Edge VPN <b>[3b]</b> with neutron's BGP framework. Will it be reasonable doing that?<u><b><br></b></u></div><div>-> Route policing <b>[3d]<br></b></div><div>-> Advertising VPN routes. <b>[3e]</b> <b><br></b></div><div><u><b></b></u></div><div><br></div><b><u>Stabilizing networking-onos [4]:</u></b><br></div><div>networking-onos was introduced in the last liberty cycle. We eye on the following items for this project:<br>-> Enhance current stability and reliability. <b>[4a]</b><br>-> Introduce devstack support. <b>[4b]</b><br>-> Develop networking-sfc driver and provide SFC PoC using networking-sfc and ONOS controller.<br><br><u><b><b><u>Stabilizing</u></b> networking-sfc [5]:<br></b></u></div><div>Will work on the current patches<b>[5a]</b> and get the code-in.<br></div><div><br><u><b></b></u><u><b>References:</b></u><br>[1].. <a href="https://bugs.launchpad.net/neutron/+bug/1476527">https://bugs.launchpad.net/neutron/+bug/1476527</a><br><br>[2].. <a href="https://github.com/openstack/neutron/blob/master/doc/source/devref/quality_of_service.rst">https://github.com/openstack/neutron/blob/master/doc/source/devref/quality_of_service.rst</a><br></div><div>[2a].. <a href="https://blueprints.launchpad.net/neutron/+spec/ml2-lb-ratelimit-support">https://blueprints.launchpad.net/neutron/+spec/ml2-lb-ratelimit-support</a><br></div><div>[2b].. <a href="https://blueprints.launchpad.net/neutron/+spec/vlan-802.1p-qos">https://blueprints.launchpad.net/neutron/+spec/vlan-802.1p-qos</a><br></div><div>[2c].. <a href="https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification">https://blueprints.launchpad.net/neutron/+spec/explicit-congestion-notification</a><br></div><div><br>[3].. <a href="https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing">https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing</a><br></div><div>[3a].. <a href="https://github.com/openstack/networking-bgpvpn">https://github.com/openstack/networking-bgpvpn</a><br></div><div>[3b].. <a href="https://github.com/stackforge/networking-edge-vpn">https://github.com/stackforge/networking-edge-vpn</a><br></div><div>[3c].. <a href="https://blueprints.launchpad.net/neutron/+spec/neutron-route-policy-support-for-dynamic-routing-protocol">https://blueprints.launchpad.net/neutron/+spec/neutron-route-policy-support-for-dynamic-routing-protocol</a><br></div><div>[3d].. <a href="https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol">https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol</a><br></div><div><br>[4].. <a href="https://github.com/openstack/networking-onos">https://github.com/openstack/networking-onos</a><br></div><div>[4a].. <a href="https://bugs.launchpad.net/networking-onos">https://bugs.launchpad.net/networking-onos</a><br></div><div>[4b].. <a href="https://bugs.launchpad.net/networking-onos/+bug/1488907">https://bugs.launchpad.net/networking-onos/+bug/1488907</a><br><br>[5].. <a href="https://github.com/openstack/networking-sfc">https://github.com/openstack/networking-sfc</a><br>[5a].. <a href="https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:master+topic:networking-sfc,n,z">https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc+branch:master+topic:networking-sfc,n,z</a><br><br></div><div>Thanks<br></div><div>Vikram <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 6:08 AM, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(Cross-posting to the operators list for feedback)<br>
<br>
Thank you Ihar for starting this up.  In the absence of any kind of<br>
blog or other outlet of my own to disseminate this, let me share my<br>
plans here...<br>
<br>
Routed Networks:<br>
<br>
My plans for Mitaka (and beyond) are around routed networks.  During<br>
Liberty, I saw the request from operators in the form of an RFE [1]<br>
(one of the first in the new RFE process I think).  The request<br>
resonated with me because I had been thinking of doing this since<br>
almost the day I started working on HP's cloud.  We went on to define<br>
use cases around this to understand what operators are looking for<br>
[2].  It seemed to me like we were on the right track.<br>
<br>
I went to work and put up a spec which proposed using provider<br>
networks for each of the network segments.  It used one more instance<br>
of a Network for the routed network and a sort of provider router<br>
which connected it to the provider Networks for the segments.  This<br>
was a short cut and the community called me on it [3].  Despite some<br>
existing leakage of L3 in to the supposedly L2 only Network model, the<br>
community wants to keep Networks L2 only.  This makes a lot of sense<br>
and I think we'll end up with a better long-term solution even if we<br>
need to go through a little more pain to get there.  I've started a<br>
new proposal [4] which adds two new L3 constructs to the model.  They<br>
are RoutedNetworkGroup and SubnetGroup.<br>
<br>
A RoutedNetworkGroup groups Networks.  It represents a bunch of L2<br>
segments that are mutually reachable via L3.  In other words, there<br>
are a bunch of L2 networks, each with its own subnet(s).  All of the<br>
subnets of the other networks are reachable through the default routes<br>
of each of the networks.<br>
<br>
We will be able to create ports using a group as a hint instead of<br>
specifying a Network explicitly.  To accomplish this, the proposal<br>
adds a new mechanism to map hosts to Networks.  In our mid-cycle, we<br>
talked through a flow where Neutron could filter host candidates given<br>
a group as a hint based on IP availability on the underlying Networks.<br>
Port creation would be passed the same group hint and a specific host<br>
to create a new port.<br>
<br>
My current understanding is that this will meet operators requirements<br>
to allow users to choose where to boot a VM based on the L3 network so<br>
that they don't have to be aware of the segments.  I'm looking to get<br>
confirmation on this.  I've spoken to Kris Lindgren about this and it<br>
seems promising.<br>
<br>
A SubnetGroup groups subnets.  I don't think the Subnet model in<br>
Neutron does a good job of representing L3.  First, floating ips<br>
connected to Network instead of Subnet, but floating ips are really an<br>
L3 thing!  Second, an L3 network often has more than just one cidr.<br>
With ipv4 specifically, it is a collection of cidrs together that is<br>
important.  The current model doesn't allow a group of subnets without<br>
a Network.  The SubnetGroup object fills this gap.  It groups Subnets;<br>
floating IPs will hang off of these instead of Networks; and they can<br>
be owned by Networks or RoutedNetworkGroups.  One day, they will also<br>
stand alone to represent a pure L3-only network (e.g. Calico).<br>
<br>
This new model will allow Neutron routers to connect to an L3 network,<br>
host floating IPs from the L3 network, and even allow routing directly<br>
to tenant networks without NAT.<br>
<br>
BGP:<br>
<br>
The BGP work is being led by Ryan Tidwell and Vikram Choudhary and is<br>
discussed weekly in the L3 team meeting [5].  I plan to continue<br>
giving my full support to this effort as it aligns very nicely with<br>
the routed networks work.<br>
<br>
Connecting Neutron routers to an L3 network needs one more thing to<br>
work.  The L3 network needs to know the next hop address for any<br>
routes behind them.  This includes floating ips and tenant networks.<br>
This can be accomplished by injecting routes in to the routers, a<br>
dynamic routing protocol, proxy arp, or whatever else.  The BGP work<br>
being done aims to fill this gap.  In short, it turns Neutron in to a<br>
BGP speaker to the L3 network.<br>
<br>
Floating IPs:<br>
<br>
This is mostly future work.  In Neutron today, a floating IP is an IP<br>
whose traffic goes to a Neutron router and is a 1-1 NAT to a private<br>
IP on the tenant network.  I'd like to generalize this concept.  For<br>
example, DNAT could be done per TCP/UDP port to different internal<br>
ports/addresses.  Gal Sagie has posted a spec something like this [6].<br>
<br>
Who says floating ips have to mean NAT?  I've seen how one operator<br>
does floating ips by instructing the VM to accept the floating IP<br>
address as one of its own.  We could also do NAT at the port on the<br>
compute host if the VM instance doesn't understand what to do with it.<br>
The point is, why does the router have to be involved, especially if<br>
we now have routed networks and BGP to work with?<br>
<br>
We could also route more than one address to an instance or even whole<br>
subnets.  Floating subnets, heh.  This might be useful for containers<br>
running inside of instances and I actually talked to a few people at<br>
LinuxCon who would like to see this happen.<br>
<br>
There is also the possibility of anycast floating ips.  Who knows what else?<br>
<br>
Carl<br>
<br>
[1] <a href="https://bugs.launchpad.net/neutron/+bug/1458890" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1458890</a><br>
[2] <a href="https://etherpad.openstack.org/p/Network_Segmentation_Usecases" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/Network_Segmentation_Usecases</a><br>
[3] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-July/thread.html#70028" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-July/thread.html#70028</a><br>
[4] <a href="https://review.openstack.org/#/c/225384/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/225384/</a><br>
[5] <a href="https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Meetings/Neutron-L3-Subteam</a><br>
[6] <a href="https://review.openstack.org/#/c/224727/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/224727/</a><br>
<div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>