Difference between revisions of "Neutron/OFAgent/Todo"
Line 28: | Line 28: | ||
**** not a big deal | **** not a big deal | ||
** neutron interface driver | ** 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 | ** 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. | ** security group. ideally implement with flows. | ||
*** cf. https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver | *** cf. https://wiki.openstack.org/wiki/Neutron/blueprint_ovs-firewall-driver |
Revision as of 04:36, 14 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.
- 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 scanning
- 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
- patch ports, multiple logical bridges
- 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.
- l2pop
- https://blueprints.launchpad.net/neutron/+spec/ofagent-l2pop
- port l2pop-based tunnel management from OVS agent
- implement local arp responder
- experimental arp proxy https://github.com/yamt/ryu/blob/arp-proxy/ryu/app/arp_proxy.py
- Reduce OVS dependencies