cisco Dynamic Fabric Automation (DFA) ML2 mechanism driver
Cisco DFA mechanism driver sends information to DCNM (Data Center Network Management) when a network is created/
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=
802_1_QBG_
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.
https:/
Blueprint information
- Status:
- Complete
- Approver:
- Edgar Magana
- Priority:
- Low
- Drafter:
- Milton Xu
- Direction:
- Needs approval
- Assignee:
- Nader Lahouti
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
- Needs Code Review
- Milestone target:
- None
- Started by
- Kyle Mestery
- Completed by
- Armando Migliaccio
Whiteboard
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:
https:/
Gerrit topic: https:/
Addressed by: https:/
Cisco DFA ML2 Mechanism Driver
Gerrit topic: https:/
Addressed by: https:/
Cisco DFA ML2 Mechanism Driver
Addressed by: https:/
Cisco DFA ML2 Mechanism Driver - Part 3
Addressed by: https:/
Cisco DFA ML2 Mechanism Driver - Part 4
Addressed by: https:/
Support for extensions in ML2
Work Items
Dependency tree
* Blueprints in grey have been implemented.