目前OpenStack网络方案存在有较多的选择，liberty发布已经有大半多时间，mikata版本也快要发布，有必要比较一下近期各种openstack网络方案的状态。
主流方案介绍
当前，比较主流的方案有如下几种：
- ovs-agent
- ofagent
- ovn
- dragonflow
- midonet/opencontrail
除此之外，还有一些闭源的商业方案，如nsx、plumgrid，以及一些试验性的开源方案如networking-odl等，本次分析暂不考虑。
现有网络方案特性集及特点
- ovs-agent
| 功能点 | 支持情况 | 备注 |
|---|---|---|
| L2 isolation using overlay | Y | 支持vlan/vxlan/gre |
| arp responder | Y | 要求ovs 2.1 + l2pop使能 |
| L3 DVR | Y | 要求每台计算节点都需要安装l3-agent，通过netns及linux协议栈实现 |
| ovsdb native | Y | 独立功能，与openflow native无关，可单独开启，有一定的性能提升 |
| openflow native | Y | ovs-agent将内置ryu，运行一个of app用来处理与本地ovs的交互，基本逻辑与原ovs-agent相似，通过driver机制实现不同方式的bridge操作，目前仍处于实验阶段 |
| security group | Y | 目前仍基于iptables，随着ovs conntrack功能的完善，可以演进至基于ovs conntrack实现 |
| dhcp | Y | 仍采用dhcp agent |
| north-sourth流量 | Y | 仍采用l3agent进行集中式转发，即便在dvr模式下 |
- ofagent
如同ofagent在openstack上的wiki所述：
OFAgent is a neutron core-plugin, implemented as ML2 mechanism driver. It aims to support pure OpenFlow1.3 switches.
ofagent关注的更多是指向向设备（如vswitch/pswitch）可移植性，因此基于纯openflow协议进行实现，而纵观业界，基本上没有基于纯openflow的openstack网络方案（目前仍成功商用的则是bigswitch的big fabric，但其采用了深度修改的openflow），因此这种方式可能是过于理想化的方案，可能并不一定能够容易落地。
从ovs的状态来看，ovs 2.5中为支持conntrack，引入了ct_state/ct这样的match/atction，这些nicira扩展落入openflow spec的时间点可能还比较长，而为了实现dv足够多的功能，ovs将会继续引入扩展，如果基于纯openflow实现的话，这些功能都将难以利用。
从wiki上的比较来看，ofagent也不支持dvr，实现上同样基于ryu，而部署模式上与ovs-agent相似，在compute/network节点都需部署。
- ovn
ovn是由vmware所主导的新项目，其介绍如下所示：
OVN, the Open Virtual Network, is a system to support virtual network abstraction. OVN complements the existing capabilities of OVS to add native support for virtual network abstractions, such as virtual L2 and L3 overlays and security groups. Services such as DHCP are also desirable features. Just like OVS, OVN’s design goal is to have a production-quality implementation that can operate at significant scale.
目前已经实现的功能集如下：
| 功能点 | 支持情况 | 备注 |
|---|---|---|
| L2 isolation using overlay | Y | hypervisor间仅支持geneve/stt，与l2gw之间可采用vxlan连接 |
| arp responder | Y | 直接基于流表实现 |
| L3 DVR | Y | 不依赖netns，基于ovs patch port及纯流表实现，对vrouter网关的icmp请求将由流表进行回复 |
| ovsdb native | Y | ovsdb目前既做northbound db，又做southbound db，同时又做hypervisor上的本地db，但操作上均是通过c语言访问native接口实现的 |
| openflow native | Y | 在hypervisor上需运行一个基于c语言实现的local controller，通过native openflow消息操作vswitchd |
| security group | N | 基于OVN ACL实现，目前已经提供部分代码，尚未实现 |
| dhcp | Y | 暂时仍采用dhcp agent，后续将内置实现 |
| north-sourth流量 | Y | 暂仍采用l3 agent，后续将内置实现，并预期支持L3HA |
nn从功能点上来说，ovn还有大量的功能有待开发，并且很多功能一方面依赖于ovs，一方面依赖于kernel，尽管邮件列表上计划在mikita版本有试验性的支持，从当前现状来看，达到生产级质量水平的可能性较小。
从架构上来看，尽管ovn也认识到northdb、southdb目前都存在ovsdb-server上存在单点故障并且ovsdb尚不支持clustering，但目前仍关注于feature的完备性，故而还未投入过多精力处理。
- dragonflow
Dragonflow implements Neutron using a lightweight embedded SDN Controller. Dragonflow is available in two configurations: Distributed and Centralized. Our project mission is to Implement advanced networking services in a manner that is efficient, elegant and resource-nimble
dragonflow由华为以色利团队开发，相比ofagent那种仅为提升性能而采用ryu实现openflow native语义的方式，dagonflow更为激进，采用了ryu app来实现l2转发及l3 dvr，并且从代码上来看，dhcp功能也已经做为ryu app实现了，并且dragonflow强调自己实现了pluggable db的支持，即通过引入外置第三方db来实现数据同步，与openstack rpc解耦，相比ovn采用ovsdb来说，db层面的可靠性及扩展性更好。
目前dragonflow的功能如下：
| 功能点 | 支持情况 | 备注 |
|---|---|---|
| L2 isolation using overlay | Y | 支持vxlan/gre |
| arp responder | Y | 基于流表实现 |
| L3 DVR | Y | 基于流表实现，无需netns |
| ovsdb native | Y | 通过ovsdb python idl访问ovsdb |
| openflow native | Y | 内置ryu，通过openflow协议处理packet-in及流表 |
| security group | N | 计划采用ovs conntrack实现，但尚未开发 |
| dhcp | Y | 采用运行在ryu里的dhcp app，实现分布式dhcp |
| xnorth-sourth流量 | Y | 仍采用l3agent进行集中式转发 |
- midonet
midonet是midokura公司开源的openstack网络方案，核心实现是基于分布式数据库（zookeeper）实现neutron数据分发，并通过ovs kmod实现转发，但在用户态完全舍弃ovs，采用自己通过java+scala实现的本地控制器，其核心转发过程称为simulation，即通过本地控制器所获知到的虚拟网络拓朴，来判断一个报文最终的转发结果，并将结果添加到ovs kmod所维护的内核态流表中。
国外有部署云客户采用该公司的方案，国内据说乐视私有云采用了该方案。
目前midonet的功能如下：
| 功能点 | 支持情况 | 备注 |
|---|---|---|
| L2 isolation using overlay | Y | 支持vxlan |
| arp responder | Y | 由本地控制器仿真实现 |
| L3 DVR | Y | 由本地控制器仿真实现，将下发至内核态流表 |
| security group | Y | 由本地控制器仿真实现 |
| dhcp | Y | 由本地控制器实现 |
| north-sourth流量 | Y | 支持DNAT/SNAT，并实现多l3时的snat同步，并可以和外部通过bgp进行l3对接 |
| load-balancer | Y | 由HA Proxy实现 |
- opencontrail
opencontrail为juniper所开发的独立网络虚拟化方案，采用专用的内核模块实现virtual network，不依赖于ovs，并采用大量的私有或公有如bgp协议实现控制平面，与juniper的设备有较好的对接，国外部分公有云如tcpcloud等采用其方案。
从部署上来说该方案与现有方案差异较大，不做过多描述。
选型建议
从上述分析来看，除社区ovsagent外，midonet/opencontrail是较为完善的方案，但前者社区较小（尽管目前部分代码已经托管至openstack官方），且采用小众语言开发，深入定制有一定的难度；如果半年内要升级的话，ovsagent似乎是较为可行的选择，半年后可以关注ovn/dragonflow等相关项目的状态再做选择。
至于转发性能方案，各方案主要还是解决管理上的复杂度，性能上dvr算是一个较大的亮点，转发性能上可以通过后续引入对组网影响较小的vxlan offload nic来提升。