拥抱开源如今成了一种潮流，既Juniper家的OpenContrail成为开源一揽子（之所以称为一揽子是用于区别现有OpenStack中由社区所维护的基于分散组件的松耦合方式）OpenStack网络虚拟化方案的首发明星后，Midukura这家公司也将自家的OpenStack网络虚拟化方案以开源方式来运作了，相比于OpenContrail的工程师的设备商研发背景，Midukura更具有IT运维背景（这点可以从其技术堆栈如scala编程语言、zookeeper/cassandra数据库、分布式架构推测出来，关于更细节的内容，后面我会陆续补充相关的分析），因此我个人还是更看好Midokura的方案，而从自己实际部署及验证的情况来看，Midokura要靠谱的多一点，当然这只是一家之言，也并非本文的重点，就不再展开。
在本文中我想谈的是，Midonet Tunnel Key的使用策略，与我们通常在基于OVS的方案中看到Tunnel Key（不论是NVGRE还是VXLAN）一般用做租户标识（即Virtual Network Identifier）不同，Midonet Tunnel Key则可以理解为按VIF分配的（实际上是基于Midonet的外部虚拟端口分配的，这里为了简化理解，可以简单认为就是按VIF分配的），而前者其实也是IETF相关标准文档所描述的用法。
Midonet之所以这样做的原因，与其架构实现有较大的关系，Midonet的架构总结起来，有如下的这几种特色：
- 全分布式架构，每个节点上运行一个Midolman进程（跑在JVM上），用于负责从分布式数据库（zookeeper）同步并发布虚拟网络配置信息，因此实现了去中心化，每个节点可以独立计算出转发结果
- 虚拟拓朴仿真机制，Midolman从VIF上收到报文后，通过拓朴转发仿真（与我们常规的Bridge->Router->Router->Bridge转发类似），就可以计算出目的VIF，从而得知目的虚拟机所在的主机，并在通过Underlay网络的IP以NVGRE/VXLAN的方式将报文Overlay传送给目的主机前就将报文编辑好
- 内核转发采用OVS datapath，即采用exact match的flow转发（megaflow暂不支持），以实现次包(即首包之后的包)的内核转发，提高转发性能
结合上面的介绍，Midonet采用基于VIF分配的原因就比较清楚的：
- 即然源端可以直接仿真出目的VIF且完成报文编辑，因此到对端唯一需要做的就是知道对端的VIF对应的OVS datapath接口是什么，NVGRE/VXLAN封装中的Tunnel Key则提供了一个简单方便的编码点，于是midonet就这么用了，另外一个Host上通过Zookeeper分配的Tunnel Key空间有10位数（非标准限制，而是Zookeeper的限制），对于一个cpu有限、memory有限的主机来说，10位数的VM已经远超能力极限的（咱们又不是天河一号，天河一号估计也不行），已经足足够用了
- Midonet采用与OVS相似的机制，转件层面采用wildcard match流表，内核采用exact match流表，因此在主机上的Midolman扫描到VIF对应的TAP接口时，Midolman就可以为这个VIF生成一条匹配域为该VIF在该主机上所申请到的Tunnel Key为匹配项的wildcard match流表，其出接口即为该VIF所对应的OVS datapath接口，当收到含有该Tunnel Key的报文时，可以直接命中该wildcard match流表，提取报文字段生成exact match流表出接口继承该wildcard流表向OVS datapath下发即可，Wildcard match流表查询及exact match流表下发会非常迅速，也弥补了Java/Scala代码在未被JIT编译器优化时的性能损失，是一个非常优雅的方案
以上便是我个人对于Midonet Tunnel Key分配的理解，在软件定义网络这股风潮日近的今天，来自于互联网IT企业所带来的新思维，新用法，也许会继续改变设备商的开发模式，设备商要想办法适应并拥抱这种变化了。