Difference between revisions of "Neutron/OFAgent/Todo"

Revision as of 08:12, 23 April 2014

OFAgent Todo
- Reduce OVS dependencies
  - patch ports, multiple logical bridges
    - https://blueprints.launchpad.net/neutron/+spec/ofagent-merge-bridges
    - https://wiki.openstack.org/wiki/Neutron/OFAgent/FlowTable
    - implement learning based on flows and packet-in. possibly with l2pop.
  - OFPP_NORMAL
    - spec-wise optional
    - an alternative is packet-in based learning. performance concern.
    - anther alternative is to query VM mac addresses neutron and install flows accordingly.
      - get_device_details doesn't return the necessary info (mac address)
      - l2pop doesn't propagate the info (device ids)
  - 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
      - https://blueprints.launchpad.net/neutron/+spec/ofagent-port-monitor
    - port external id
      - currently the agent uses on openstack device uuids associated to OFP ports by neutron/nova interface drivers and/or libvirt
      - there seems no pure-openflow way to do the same
      - 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
    - ideally use OF-Config
    - but this likely remains switch-dependant
    - 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
  - the way to configure public network (br-ex)
    - similar to physical networks
  - stop assuming the existence of local ports
    - eg. setup_physical_bridges
    - not a big deal
- neutron interface driver
  - ideally use OF-Config
  - investigate if the existing IVS driver is usable for our purpose, at least for IVS.
- nova interface driver
  - ideally use OF-Config
  - investigate if the existing IVS driver is usable for our purpose, at least for IVS.
  - probably it's better to avoid touching libvirt unless absolutely necessary
- security group. ideally implement with flows.
  - cf. similar BP for OVS agent https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver
- l2pop
  - https://blueprints.launchpad.net/neutron/+spec/ofagent-l2pop
  - port l2pop-based tunnel management from OVS agent
  - implement local arp responder
    - cf. experimental arp proxy https://github.com/yamt/ryu/blob/arp-proxy/ryu/app/arp_proxy.py

@@ Line 5: / Line 5: @@
 **** https://wiki.openstack.org/wiki/Neutron/OFAgent/FlowTable
 **** implement learning based on flows and packet-in.  possibly with l2pop.
+*** OFPP_NORMAL
+**** spec-wise optional
+**** an alternative is packet-in based learning.  performance concern.
+**** anther alternative is to query VM mac addresses neutron and install flows accordingly.
+***** get_device_details doesn't return the necessary info  (mac address)
+***** l2pop doesn't propagate the info  (device ids)
 *** OVSDB
 **** port scanning