Difference between revisions of "Neutron/OFAgent/Todo"

Revision as of 04:52, 9 July 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.
      • another 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
      • bridge identity
        • currently bridges are identified by name (eg. br-int)
        • it's more portable to use datapath-id
        • or use OFPMP_DESC dp_desc?
      • 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
        • we plan to desupport "ancillary" bridges (aka br-ex)
      • 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
      • covered by https://blueprints.launchpad.net/neutron/+spec/ofagent-merge-bridges
    • tunnel ports
      • ideally use OF-Config
      • but this likely remains switch-dependant
      • factor out the code into "OVS" sub-driver.
        • https://blueprints.launchpad.net/neutron/+spec/ofagent-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
      • https://review.openstack.org/#/c/87440/
    • implement local arp responder
      • wip https://github.com/fkakuma/neutron/tree/ofagent/l2pop.arp_responder2
      • cf. experimental arp proxy https://github.com/yamt/ryu/blob/arp-proxy/ryu/app/arp_proxy.py