Neutron中有个  MAC/IP 防篡改的功能，即 PortSecurity，虚拟机只能以Neutron分配的 MAC/IP跟外界通行，例如，在两台或多台虚拟机内部利用keepalived通过VRRP做 HA，通过VIP对外部提供服务；这样为突破PortSecurity限制，首先需要修改这一组VM的Port 的allowed_address_pair来允许该端口上VIP的访问。

更进一步的情况，租户想要给该VIP绑定FloatingIP，在公网提供服务。然而此时，该VIP 在多个VM的Port 的allowed_address_pair上，并不属于某个Port，Neutron拿不到该Port 的正确binding信息，导致DVR不能正确处理该FloatingIP。

我们在United Networing Platform的DVR/CVR使用场景时讨论了这种问题，本周社区在邮件列表中刚好讨论了该使用场景，起因是Ocativa HA的实现问题，见https://bugs.launchpad.net/neutron/+bug/1583694，DVR实例会在每台计算节点上动态的创建和删除，并且重度依赖port binding的数据。这种场景下的问题根本在哪里？该场景下有多个ACTIVE 的VM Port跟相同的 allowed_address_pair关联，并且VM可能分布在不同的Hypervisor上。不能在每一个可能的Hypervisor上都创建<FloatingIP, VIP>的NAT关系，因为这样会使External Network感到困惑，不知道真实的FloatingIP到底在那个Hypervisor上，问题类似于无法直接实现分布式SNAT。

对于集中式的Classic Router，网关只会在网络节点这一个地方，并且NAT规则的处理也不依赖于port binding，所以上述问题就不复存在。

解决DVR with VRRP in VM的问题，有多重可选的方案：

［1］Neutron控制平面感知到一组VM内部VIP的状态和切换(active/standby)。 keepalived在状态切换时会发送GARP来更新 VIP 的 MAC和可达性，此时Router namespace的arp table也会更新，并且请求VIP时只有master VM会应答，所以Neutron控制平面可以通过这种方式来感知VIP的状态和切换；

［2］在该使用场景下用CVR 替代DVR，或者选取折方案，在集中式的处理南北向流量。这种这种的实现上需要在FloatingIP的处理流程中增加更多的判断逻辑，增加已有代码复杂度。

此外，在United Networing Platform的DVR/CVR使用场景的讨论中存在另一种情况需要使用CVR，即租户自己要使用Service VM做虚拟路由和安全网关，通过Double NAT的方式访问公网。以HillStone Service VM 为例，Network2的虚拟机需要通过HillStone实现SNAT & DNAT访问公网，那么需要将FloatingIP绑定到Network 0网段一个并没有binding  Port上，然后在HillStone Service VM内部写NAT规则。由于该Port 没有 binding数据，所以只能使用CVR。

完成了networking-ovn实现ML2 Driver： https://bugs.launchpad.net/networking-ovn/+bug/1578198

关于Ml2 + OVS  to OVN 的 migration，是否在不久就能使用OVN 作为 ML2的默认Driver 呢？非常期待，可惜还没有开始提交代码！ https://bugs.launchpad.net/networking-ovn/+bug/1528674

用本地控制器来做分布式的DHCP，在某些厂商的方案中已经实现，现在OVN通过增加了 Logical_Port 的 dhcp options 也已经实现，networking-ovn正在做这个功能 https://bugs.launchpad.net/networking-ovn/+bug/1514488