Difference between revisions of "Neutron/ModularL2Agent"

Latest revision as of 13:51, 6 May 2014

Here we are collecting information on possible directions wrt building a modular L2 agent.

Introduction

As the number of L2 agents increase and considering similarities between these agents, we are making an effort to identify possible strategies for building a unified L2 agent where we reduce the amount of redundant code currently used by L2 agents. Furthermore, as more plugins and mechanism drivers are added, those which require L2 agents can benefit from a modular L2 agent and possibly use pieces of the agent that suits them.

This effort aims to design and develop a framework for reducing the cost of maintaining the agent code and reducing the effort required for building a new agent. Furthermore, we will look into possible opportunities in improving the performance and stability of agents. While the focus of the effort will be on L2 agents we may look into establishing a framework for all Neutron agents.

Here is the ether pad for the Juno design session: juno/neutron/modular-l2-agent

Possible Directions

Agent Drivers

One of the possible directions is to model the L2 agent after how ML2 plugin is organized and provide support for "drivers."

Extension Drivers

Another direction is to separate the support for the core API and that for extensions being supported by the plugin. Right now security groups and l2pop use the L2 agent and with the proposal for supporting arbitrary number of extensions by the ML2 plugin and mechanism drivers, other extensions may require support from the L2 agent. One possible solution is having pluggable drivers for every extension. The outstanding issue to resolve is the coordination mechanism between these drivers.

Related Design Sessions and Blueprints

Support for mechanism driver specific extensions: design session and blueprint
DVR Progress Update session: design session
Support for multiple OVS switches, one for each feature/extension: here
OVS based security groups: here
Configuration agents: here
Device agents: here

Comparison Chart

	openvswitch	linuxbridge	hyperv	ofagent	mlnx
Monitoring	ovsdb	OS	Msvm	Currently ovsdb. Planned: OpenFlow	OS
Flows	ovs-ofctl	-		Embedded OF controller
Local isolation	vlan tag	bridge/vlan		Currently VLAN tag. Planned: OF metadata	vlan tag

Security Groups	Y	Y	Y	Y	N
L2pop	Y	Y	N	N	N

@@ Line 1: / Line 1: @@
+Here we are collecting information on possible directions wrt building a modular L2 agent.
+== Introduction ==
+As the number of L2 agents increase and considering similarities between these agents, we are making an effort to identify possible strategies for building a unified L2 agent where we reduce the amount of redundant code currently used by L2 agents. Furthermore, as more plugins and mechanism drivers are added, those which require L2 agents can benefit from a modular L2 agent and possibly use pieces of the agent that suits them.
+This effort aims to design and develop a framework for reducing the cost of maintaining the agent code and reducing the effort required for building a new agent. Furthermore, we will look into possible opportunities in improving the performance and stability of agents. While the focus of the effort will be on L2 agents we may look into establishing a framework for all Neutron agents.
+Here is the ether pad for the Juno design session: [https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent  juno/neutron/modular-l2-agent ]
+== Possible Directions ==
+=== Agent Drivers ===
+One of the possible directions is to model the L2 agent after how ML2 plugin is organized and provide support for "drivers."
-Here we are collecting information on possible directions wrt building a modular L2 agent.
+=== Extension Drivers ===
+Another direction is to separate the support for the core API and that for extensions being supported by the plugin. Right now security groups and l2pop use the L2 agent and with the proposal for supporting arbitrary number of extensions by the ML2 plugin and mechanism drivers, other extensions may require support from the L2 agent. One possible solution is having pluggable drivers for every extension. The outstanding issue to resolve is the coordination mechanism between these drivers.
+== Related Design Sessions and Blueprints ==
+* Support for mechanism driver specific extensions: [https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support design session] and [https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions blueprint]
+* DVR Progress Update session: [https://etherpad.openstack.org/p/Distributed-Virtual-Router design session]
+* Support for multiple OVS switches, one for each feature/extension: [http://summit.openstack.org/cfp/details/391 here]
+* OVS based security groups: [http://summit.openstack.org/cfp/details/155 here]
+* Configuration agents: [http://summit.openstack.org/cfp/details/409 here]
+* Device agents: [http://summit.openstack.org/cfp/details/395 here]
 == Comparison Chart ==
@@ Line 16: / Line 40: @@
 | OS
 | Msvm
-| ovsdb
+| Currently ovsdb.  <br/> [https://blueprints.launchpad.net/neutron/+spec/ofagent-port-monitor Planned: OpenFlow]
-|
+| OS
 |-
 | Flows
 | ovs-ofctl
+| -
 |
-|
+| Embedded OF controller
-|
 |
 |-
 | Local isolation
 | vlan tag
+| bridge/vlan
 |
-|
+| Currently VLAN tag.  <br/> [https://blueprints.launchpad.net/neutron/+spec/ofagent-merge-bridges Planned: OF metadata]
-|
+| vlan tag
-|
 |-
 ||
@@ Line 45: / Line 69: @@
 | Y
 | Y
-| Y
+| N
 |-
 | L2pop
@@ Line 57: / Line 81: @@
 == Related documents ==
-* A summary of the differences between ova and ofagent (current and planned) agents are listed [https://wiki.openstack.org/wiki/Neutron/OFAgent/ComparisonWithOVS here]
+* A summary of the differences between openvswitch and ofagent (current and planned) agents are listed [https://wiki.openstack.org/wiki/Neutron/OFAgent/ComparisonWithOVS here]