Jump to: navigation, search

Difference between revisions of "Neutron/OFAgent"

Line 9: Line 9:
 
*** OVSDB
 
*** OVSDB
 
**** port scanning
 
**** port scanning
***** use port desc and ofp_port_status instead
+
***** currently periodically scannig the list of ports and its status using ovs-vsctl
 +
***** use openflow port desc stats and ofp_port_status instead
 
**** port external id
 
**** port external id
 +
***** there's no pure-openflow way to associate openstack device uuids to OFP ports.
 
***** probably use tapXXXX, which is available as ofp_port.name.  ML2 plugin already accepts tapXXXX for linuxbridge.
 
***** probably use tapXXXX, which is available as ofp_port.name.  ML2 plugin already accepts tapXXXX for linuxbridge.
 
**** add-br, set-controller, set bridge protocols
 
**** add-br, set-controller, set bridge protocols
Line 17: Line 19:
 
***** move the one-time setup code to devstack
 
***** move the one-time setup code to devstack
 
*** port-based VLAN
 
*** port-based VLAN
**** install appropriate flows to push/pop tags.
+
**** currently using ovs-vsctl to set up port-based VLANs
 +
**** install appropriate flows to push/pop tags instead
 
*** tunnel ports
 
*** tunnel ports
 
**** factor out the code into "OVS" sub-driver.
 
**** factor out the code into "OVS" sub-driver.

Revision as of 04:22, 14 April 2014

OFAgent is a neutron core-plugin (ML2 mechanism driver) aims to support pure OpenFlow1.3 switches.

  • Todo
    • Reduce OVS dependencies
      • patch ports, multiple logical bridges
      • OVSDB
        • port scanning
          • currently periodically scannig the list of ports and its status using ovs-vsctl
          • use openflow port desc stats and ofp_port_status instead
        • port external id
          • there's no pure-openflow way to associate openstack device uuids to OFP ports.
          • probably use tapXXXX, which is available as ofp_port.name. ML2 plugin already accepts tapXXXX for linuxbridge.
        • add-br, set-controller, set bridge protocols
          • factor out to "OVS" sub-driver
          • use OF-Config
          • move the one-time setup code to devstack
      • port-based VLAN
        • currently using ovs-vsctl to set up port-based VLANs
        • install appropriate flows to push/pop tags instead
      • tunnel ports
        • factor out the code into "OVS" sub-driver.
      • the way to configure physical networks
        • it would be more straightforward to specify an interface (eth0) rather than a bridge (br-eth0)
        • this will be user-visible changes
      • stop assuming the existence of local ports
        • eg. setup_physical_bridges
        • not a big deal
    • neutron interface driver
    • nova interface driver
    • security group. ideally implement with flows.
    • l2pop