TricircleDiscuzZone

JunSik experiment
For the automation of VXLAN networking in Multi-region OpenStack, we configure virtual network inside a server as shown in the below picture.



To connect Multi-region OpenStack instances, I add an additional bridge named "br-cap" and configure tunnel ports on the bridge. And the bridge "br-cap" is controlled by ONOS SDN controller. To automate the configuration, I introduced a concept of template-based automation. I defined a self-defined template format to describe virtual network topology over multiple servers. Then my tool automates the configuration of OVS bridges and VXLAN ports via OVSDB protocol, and calls ONOS APIs to down OpenFlow rules to "br-cap" bridges. As the basic flow rules, we just set broadcast flow rules not fine-grained flow rules. For example, a packet arrives br-cap from br-int, then "br-cap" broadcast the packet to all tunnels.

tunnel termination point as part of the binding details
Kevin recap for the Barcelona design summit session: http://lists.openstack.org/pipermail/openstack-dev/2016-November/107061.html

L2pop calculates information on the fly to determine tunnel termination endpoints. This is racey (out of order tunnel notifications are not handled) and leads to lots of complexity involving lookups to agent tables, etc. This also makes it very difficult to integrate external devices because they have no way of informing the agents of their tunnel termination endpoint.

We'd like to formalize the tunnel termination point by adding it to the port binding data model just like other encapsulation details (bound segment, segmentation id, etc). This will allow mech drivers to bind ports not based on agents and allow seamless integration with agent-based ports. The L2pop server-side logic would go away since agents would setup forwarding entries just based on the latest data on the port models delivered via push notifications.

This will require some changes on the server side in the port binding process to have the mech drivers provide the tunnel termination point as part of the binding details. The agent side will also require a few changes to have its tunnel forming logic be derived from push notifications instead of tunnel and fdb notifications.

=== flooding vteps in network (VTEP in network) === Through add remote VTEPs in other Neutron to the network in local Neutron, then one network can be extended to other openstack via VxLAN. When we talked with Kevin in Barcelona summit, Kevin thinks that the (VTEP in port) will be a better solution.

https://review.openstack.org/#/c/282180/ {     "network": { "status": "ACTIVE", "name": "net1", "admin_state_up": true, "tenant_id": "9bacb3c5d39d41a79512987f338cf177", "mtu": 0, "shared": false, "id": "4e8e5957-649f-477b-9e5b-f1f75b21c03c" "provider:network_type": "vxlan", "provider:segmentation_id": "1022", "provider:flooding_vteps":[ {"ip_address":"192.168.1.1", "dstport": "5566"} ],       "router:external":True }   }