.. _ovn_gaps:

Gaps from ML2/OVS
=================

This is a list of some of the currently known gaps between ML2/OVS and OVN.
It is not a complete list, but is enough to be used as a starting point for
implementors working on closing these gaps. A TODO list for OVN is located
at [1]_.

* QoS minimum bandwidth allocation in Placement API

  ML2/OVN integration with the Nova placement API to provide guaranteed
  minimum bandwidth for ports [2]_. Work in progress, see [3]_

* IPv6 Prefix Delegation

  Currently ML2/OVN doesn't implement IPv6 prefix delegation. OVN logical
  routers have this capability implemented in [4]_ and we have an open RFE to
  fill this gap [5]_.

* DHCP service for instances

  ML2/OVS adds packet filtering rules to every instance that allow DHCP queries
  from instances to reach the DHCP agent. For OVN this traffic has to be explicitly
  allowed by security group rules attached to the instance. Note that the default
  security group does allow all outgoing traffic, so this only becomes relevant
  when using custom security groups [6]_. Proposed patch is [7]_ but it
  needs to be revived and updated.

* DNS resolution for instances

  OVN cannot use the host's networking for DNS resolution, so Case 2b in [8]_ can
  only be used when additional DHCP agents are deployed. For Case 2a a different
  configuration option has to be used in ``ml2_conf.ini``::

    [ovn]
    dns_servers = 203.0.113.8, 198.51.100.53

  OVN answers queries for hosts and IP addresses in tenant networks by spoofing
  responses from the configured DNS servers. This may lead to confusion in
  debugging.

  OVN can only answer queries that are sent via UDP, queries that use TCP will be
  ignored by OVN and forwarded to the configured resolvers.

  OVN can only answer queries with no additional options being set (EDNS). Such
  queries depending on the OVN version will either get broken responses or will
  also be forwarded to the configured resolvers.

* IPv6 NDP proxy

  The NDP proxy functionality for IPv6 addresses is not supported by OVN.

* East/West Fragmentation

  The core OVN implementation does not support fragmentation of East/West
  traffic using an OVN router between two private networks. This is being
  tracked in [9]_ and [10]_.

* North/South Fragmentation and path MTU discovery

  OVN does not correctly fragment IPv4 packets when the MTU of the target
  network is smaller than the MTU of the source network. Instead, affected
  packets could be silently dropped depending on the direction. OVN will
  also not generate ICMP "packet too big" responses for packets that have
  the DF bit set, even when the necessary configuration option is used
  in ``ml2_conf.ini``::

    [ovn]
    ovn_emit_need_to_frag = true

  This makes path MTU discovery fail, and is being tracked in [9]_ and [11]_.

References
----------

.. [1] https://github.com/ovn-org/ovn/blob/master/TODO.rst
.. [2] https://specs.openstack.org/openstack/neutron-specs/specs/rocky/minimum-bandwidth-allocation-placement-api.html
.. [3] https://review.opendev.org/c/openstack/neutron/+/786478
.. [4] https://patchwork.ozlabs.org/project/openvswitch/patch/6aec0fb280f610a2083fbb6c61e251b1d237b21f.1576840560.git.lorenzo.bianconi@redhat.com/
.. [5] https://bugs.launchpad.net/neutron/+bug/1895972
.. [6] https://bugs.launchpad.net/neutron/+bug/1926515
.. [7] https://review.opendev.org/c/openstack/neutron/+/788594
.. [8] https://docs.openstack.org/neutron/latest/admin/config-dns-res.html
.. [9] https://bugs.launchpad.net/neutron/+bug/2032817
.. [10] https://bugzilla.redhat.com/show_bug.cgi?id=2238494
.. [11] https://bugzilla.redhat.com/show_bug.cgi?id=2238969
