Skip to content

Latest commit

 

History

History
150 lines (102 loc) · 5.19 KB

TODO.rst

File metadata and controls

150 lines (102 loc) · 5.19 KB
Raw

OVN To-do List

  • Get incremental updates in ovn-controller and ovn-northd in some sensible way.

  • Live migration.

    Russell Bryant: "When you're ready to have the destination take over, you have to remove the iface-id from the source and add it at the destination and I think it'd typically be configured on both ends, since it's a clone of the source VM (and it's config)."

  • VLAN trunk ports.

    Russell Bryant: "Today that would require creating 4096 ports for the VM and attach to 4096 OVN networks, so doable, but not quite ideal."

  • Service function chaining.

  • MAC learning.

    Han Zhou: "To support VMs that hosts workloads with their own macs, e.g. containers, if not using OVN native container support."

  • Hitless upgrade, especially for data plane.

  • Use OpenFlow "bundles" for transactional data plane updates.

  • Dynamic IP to MAC binding enhancements.

    OVN has basic support for establishing IP to MAC bindings dynamically, using ARP.

    • Ratelimiting.

      From casual observation, Linux appears to generate at most one ARP per second per destination.

      This might be supported by adding a new OVN logical action for rate-limiting.

    • Tracking queries

      It's probably best to only record in the database responses to queries actually issued by an L3 logical router, so somehow they have to be tracked, probably by putting a tentative binding without a MAC address into the database.

    • Renewal and expiration.

      Something needs to make sure that bindings remain valid and expire those that become stale.

      One way to do this might be to add some support for time to the database server itself.

    • Table size limiting.

      The table of MAC bindings must not be allowed to grow unreasonably large.

  • MTU handling (fragmentation on output)

  • ovsdb-server

    ovsdb-server should have adequate features for OVN but it probably needs work for scale and possibly for availability as deployments grow. Here are some thoughts.

    • Multithreading.

      If it turns out that other changes don't let ovsdb-server scale adequately, we can multithread ovsdb-server. Initially one might only break protocol handling into separate threads, leaving the actual database work serialized through a lock.

  • Support multiple tunnel encapsulations in Chassis.

    So far, both ovn-controller and ovn-controller-vtep only allow chassis to have one tunnel encapsulation entry. We should extend the implementation to support multiple tunnel encapsulations.

  • Update learned MAC addresses from VTEP to OVN

    The VTEP gateway stores all MAC addresses learned from its physical interfaces in the 'Ucast_Macs_Local' and the 'Mcast_Macs_Local' tables. ovn-controller-vtep should be able to update that information back to ovn-sb database, so that other chassis know where to send packets destined to the extended external network instead of broadcasting.

  • Translate ovn-sb Multicast_Group table into VTEP config

    The ovn-controller-vtep daemon should be able to translate the Multicast_Group table entry in ovn-sb database into Mcast_Macs_Remote table configuration in VTEP database.

  • OVN OCF pacemaker script to support Active / Passive HA for OVN dbs provides the option to configure the inactivity_probe value. The default 5 seconds inactivity_probe value is not sufficient and ovsdb-server drops the client IDL connections for openstack deployments when the neutron server is heavily loaded.

    We need to find a proper solution to solve this issue instead of increasing the inactivity_probe value.

  • ACL

    • Support FTP ALGs.
    • Support reject action.

  • OVN Interconnection

    • Packaging for RHEL, Debian, etc.

  • ovn-controller: Stop copying the local OVS configuration into the Chassis external_ids column (same for the "is-remote" configuration from ovn-ic) a few releases after the 20.06 version (21.06 maybe ?).

  • ovn-controller: Remove backwards compatibility for Southbound DB Port_Group names in expr.c a few releases after the 20.09 version. Right now ovn-controller maintains backwards compatibility when connecting to a SB database that doesn't store Port_Group.name as <Logical_Datapath.tunnel_key_NB-Port_Group.name>. This causes an additional hashtable lookup in parse_port_group() which can be avoided when we are sure that the Southbound DB uses the new format.