cisco Dynamic Fabric Automation (DFA) ML2 mechanism driver

Registered by Milton Xu

Cisco DFA mechanism driver sends information to DCNM (Data Center Network Management) when a network is created/updated/deleted. It also sends information related to network and instance to an external process running VDP which is used to communicate to the DFA fabric edge switch, when an instance is created/deleted.

This is for topologes where Openstack compute nodes are connected to the external switches or fabrics. The fabric comprising of the switches support more than 4K segments. In some of these architectures network based overlay (and not host based overlay) is deployed. So, one should be able to create more than 4K networks in Openstack. But, the VLAN to be used for communication with the switches is assigned by the switches using 802.1QBG (VDP) protocol. The VM's sends .1q frames to the switches and the switches associate it to the segment (VNI in case of VXLAN).
With the current model:
1. One cannot use a type driver of VLAN because of the 4K limitation. Also a type driver of VXLAN or GRE cannot be used because that may mean host based overlay.
2. Also the programming of flows should be done after communicating the vNIC information to lldpad and lldpad communicates with the leaf switches and return the VLAN to be used by this VM. The Openstack module running in the compute communicate with VDP module (Opensource lldpad) running there. The VLAN is of local significance between the compute node and the switch to which it is connected.

In order to achieve this, an integrated functionality is required. The type driver can still be Tunnel. But, we need extra configuration parameters as below:
HOST_OVERLAY=True/False /* By default this will be True retaining the existing behavior */
802_1_QBG_VDP=True/False /* By default this will be False retaining the existing behavior */

When Host Overlay is set to False, then changes need to be done in ovs_neutron_agent code to not create the br-tun bridge.
When VDP Parameter is set to True, the add_flow should not create the flow for VLAN translation. Rather flow should be created where communication with LLDPAD happens and VLAN is retrieved. Additionally, more VDP configuration parameters will be defined for the protocol like the Manager ID, VSI Type etc.

Blueprint information

Edgar Magana
Milton Xu
Needs approval
Nader Lahouti
Series goal:
Needs Code Review
Milestone target:
Started by
Kyle Mestery
Completed by
Armando Migliaccio

Related branches



September-3 (mestery): Moving out of Juno, needs to be proposed again for Kilo.

20-July (mestery): Moving to Juno-3.

Realistically, this will need the spec approved, the code reviewed and approved, and third-party CI functioning. In two weeks, it's doubtful all of this will happen, thus moving this to Juno-2.

We would like to get the implementation reviewed and committed for the Juno release

Please let us know what needs to be done for this blueprint in order to get approve process started.

[June-27-2014] The code committed for the review:

Gerrit topic:,topic:bp/which,n,z

Addressed by:
    Cisco DFA ML2 Mechanism Driver

Gerrit topic:,topic:bp/ml2-mechanism-driver-for-cisco-dfa,n,z

Addressed by:
    Cisco DFA ML2 Mechanism Driver

Addressed by:
    Cisco DFA ML2 Mechanism Driver - Part 3

Addressed by:
    Cisco DFA ML2 Mechanism Driver - Part 4

Addressed by:
    Support for extensions in ML2


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.