ovn-sb - OVN_Southbound database schema
       This database holds logical and physical configuration and state
       for the Open Virtual Network (OVN) system to support virtual
       network abstraction. For an introduction to OVN, please see
       ovn-architecture(7).
       The OVN Southbound database sits at the center of the OVN
       architecture. It is the one component that speaks both southbound
       directly to all the hypervisors and gateways, via
       ovn-controller/ovn-controller-vtep, and northbound to the Cloud
       Management System, via ovn-northd:
   Database Structure
       The OVN Southbound database contains classes of data with
       different properties, as described in the sections below.
     Physical network
       Physical network tables contain information about the chassis
       nodes in the system. This contains all the information necessary
       to wire the overlay, such as IP addresses, supported tunnel
       types, and security keys.
       The amount of physical network data is small (O(n) in the number
       of chassis) and it changes infrequently, so it can be replicated
       to every chassis.
       The Chassis and Encap tables are the physical network tables.
     Logical Network
       Logical network tables contain the topology of logical switches
       and routers, ACLs, firewall rules, and everything needed to
       describe how packets traverse a logical network, represented as
       logical datapath flows (see Logical Datapath Flows, below).
       Logical network data may be large (O(n) in the number of logical
       ports, ACL rules, etc.). Thus, to improve scaling, each chassis
       should receive only data related to logical networks in which
       that chassis participates.
       The logical network data is ultimately controlled by the cloud
       management system (CMS) running northbound of OVN. That CMS
       determines the entire OVN logical configuration and therefore the
       logical network data at any given time is a deterministic
       function of the CMS's configuration, although that happens
       indirectly via the OVN_Northbound database and ovn-northd.
       Logical network data is likely to change more quickly than
       physical network data. This is especially true in a container
       environment where containers are created and destroyed (and
       therefore added to and deleted from logical switches) quickly.
       The Logical_Flow, Multicast_Group, Address_Group, DHCP_Options,
       DHCPv6_Options, and DNS tables contain logical network data.
     Logical-physical bindings
       These tables link logical and physical components. They show the
       current placement of logical components (such as VMs and VIFs)
       onto chassis, and map logical entities to the values that
       represent them in tunnel encapsulations.
       These tables change frequently, at least every time a VM powers
       up or down or migrates, and especially quickly in a container
       environment. The amount of data per VM (or VIF) is small.
       Each chassis is authoritative about the VMs and VIFs that it
       hosts at any given time and can efficiently flood that state to a
       central location, so the consistency needs are minimal.
       The Port_Binding and Datapath_Binding tables contain binding
       data.
     MAC bindings
       The MAC_Binding table tracks the bindings from IP addresses to
       Ethernet addresses that are dynamically discovered using ARP (for
       IPv4) and neighbor discovery (for IPv6). Usually, IP-to-MAC
       bindings for virtual machines are statically populated into the
       Port_Binding table, so MAC_Binding is primarily used to discover
       bindings on physical networks.
   Common Columns
       Some tables contain a special column named external_ids. This
       column has the same form and purpose each place that it appears,
       so we describe it here to save space later.
              external_ids: map of string-string pairs
                     Key-value pairs for use by the software that
                     manages the OVN Southbound database rather than by
                     ovn-controller/ovn-controller-vtep. In particular,
                     ovn-northd can use key-value pairs in this column
                     to relate entities in the southbound database to
                     higher-level entities (such as entities in the OVN
                     Northbound database). Individual key-value pairs in
                     this column may be documented in some cases to aid
                     in understanding and troubleshooting, but the
                     reader should not mistake such documentation as
                     comprehensive.