ovn-nb: Add support for IP+MAC binding pairs in Port_Binding 'address'.
[cascardo/ovs.git] / ovn / ovn-nb.xml
index 42a94b9..7f6f703 100644 (file)
     <column name="type">
       <p>
       Specify a type for this logical port.  Logical ports can be used to model
-      other types of connectivity into an OVN logical switch.  Leaving this column
-      blank maintains the default logical port behavior.
+      other types of connectivity into an OVN logical switch.  Leaving this
+      column blank maintains the default logical port behavior, which is
+      for a VM (or VIF) interface.  The following other types are defined:
       </p>
 
-      <p>
-        When this column is set to <code>localnet</code>, this logical port
-        represents a connection to a locally accessible network from each
-        <code>ovn-controller</code> instance.  A logical switch can only have a
-        single <code>localnet</code> port attached and at most one regular
-        logical port.  This is used to model direct connectivity to an existing
-        network.
-      </p>
+      <dl>
+        <dt><code>localnet</code></dt>
+        <dd>A connection to a locally accessible network from each
+        <code>ovn-controller</code> instance.  A logical switch can only
+        have a single <code>localnet</code> port attached and at most one
+        regular logical port.  This is used to model direct connectivity
+        to an existing network.</dd>
+      </dl>
+
+      <dl>
+        <dt><code>vtep</code></dt>
+        <dd>A port to a logical switch on a VTEP gateway.  In order
+        to get this port correctly recognized by the OVN controller, the
+        <ref column="options" table="Logical_Port"/>:<code>vtep-physical-switch</code>
+        and <ref column="options" table="Logical_Port"/>:<code>vtep-logical-switch</code>
+        must also be defined.</dd>
+      </dl>
     </column>
 
     <column name="options">
       <p>
         This column provides key/value settings specific to the logical port
-        <ref column="type"/>.
+        <ref column="type"/>.  The following options are defined:
       </p>
 
-      <p>
-        When <ref column="type"/> is set to <code>localnet</code>, you must set
-        the option <code>network_name</code>.  <code>ovn-controller</code> uses
-        local configuration to determine exactly how to connect to this locally
-        accessible network.
-      </p>
+      <dl>
+        <dt><code>network_name</code></dt>
+        <dd>
+          Must be set when <ref column="type"/> is <code>localnet</code>.
+          <code>ovn-controller</code> uses local configuration to determine
+          exactly how to connect to this locally accessible network.
+        </dd>
+      </dl>
+
+      <dl>
+        <dt><code>vtep-physical-switch</code></dt>
+        <dd>
+          The name of the VTEP gateway.  Must be set when
+          <ref column="type"/> is <code>vtep</code>.
+        </dd>
+      </dl>
+
+      <dl>
+        <dt><code>vtep-logical-switch</code></dt>
+        <dd>
+          A logical switch name connected by the VTEP gateway.  Must be
+          set when <ref column="type"/> is <code>vtep</code>.
+        </dd>
+      </dl>
     </column>
 
     <column name="parent_name">
     </column>
 
     <column name="tag">
-      When <ref column="name"/> identifies the interface of a container
-      spawned inside a tenant VM, this column identifies the VLAN tag in
-      the network traffic associated with that container's network interface.
-      When there are multiple container interfaces inside a VM, all of
-      them send their network traffic through a single VM network interface and
-      this value helps OVN identify the correct container interface.
+     <p>
+      When <ref column="type"/> is empty and <ref column="name"/> identifies
+      the interface of a container spawned inside a tenant VM, this column
+      identifies the VLAN tag in the network traffic associated with that
+      container's network interface. When there are multiple container
+      interfaces inside a VM, all of them send their network traffic through a
+      single VM network interface and this value helps OVN identify the correct
+      container interface.
+     </p>
+
+     <p>
+      When <ref column="type"/> is set to <code>localnet</code>, this can be
+      set to indicate that the port represents a connection to a specific
+      VLAN on a locally accessible network. The VLAN ID is used to match
+      incoming traffic and is also added to outgoing traffic.
+     </p>
     </column>
 
     <column name="up">
       ingress and egress traffic dropped.
     </column>
 
-    <column name="macs">
-      The logical port's own Ethernet address or addresses, each in the form
-      <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>.
-      Like a physical Ethernet NIC, a logical port ordinarily has a single
-      fixed Ethernet address.  The string <code>unknown</code> is also allowed
-      to indicate that the logical port has an unknown set of (additional)
-      source addresses.
+    <column name="addresses">
+      <p>
+        Addresses owned by the logical port.
+      </p>
+
+      <p>
+        Each element in the set must take one of the following forms:
+      </p>
+
+      <dl>
+        <dt><code><var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var></code></dt>
+        <dd>
+          <p>
+            An Ethernet address owned by the logical port.  Like a physical
+            Ethernet NIC, a logical port ordinarily has a single fixed Ethernet
+            address.
+          </p>
+
+          <p>
+            When a OVN logical switch processes a unicast Ethernet frame whose
+            destination MAC address is in a logical port's <ref
+            column="addresses"/> column, it delivers it only to that port, as
+            if a MAC learning process had learned that MAC address on the port.
+          </p>
+        </dd>
+
+        <dt><code><var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var> <var>a</var>.<var>b</var>.<var>c</var>.<var>d</var></code></dt>
+        <dd>
+          <p>
+            This form has all the effects of the previous form.  It also
+            indicates that the logical port owns the given IPv4 address.
+          </p>
+
+          <p>
+            The OVN logical switch uses this information to synthesize
+            responses to ARP requests without traversing the physical network.
+            The OVN logical router connected to the logical switch, if any,
+            uses this information to avoid issuing ARP requests for logical
+            switch ports.
+          </p>
+        </dd>
+
+        <dt><code>unknown</code></dt>
+        <dd>
+          This indicates that the logical port has an unknown set of Ethernet
+          addresses.  When an OVN logical switch processes a unicast Ethernet
+          frame whose destination MAC address is not in any logical port's <ref
+          column="addresses"/> column, it delivers it to the port (or ports)
+          whose <ref column="addresses"/> columns include <code>unknown</code>.
+        </dd>
+      </dl>
     </column>
 
     <column name="port_security">
       </p>
 
       <p>
-       This specification will be extended to support L3 port security.
+        This specification will be extended to support L3 port security.
       </p>
     </column>
 
     </p>
 
     <column name="priority">
-      The ACL rule's priority.  Rules with numerically higher priority take
-      precedence over those with lower.  If two ACL rules with the same
-      priority both match, then the one actually applied to a packet is
-      undefined.
+      <p>
+        The ACL rule's priority.  Rules with numerically higher priority
+        take precedence over those with lower.  If two ACL rules with
+        the same priority both match, then the one actually applied to a
+        packet is undefined.
+      </p>
+
+      <p>
+        Return traffic from an <code>allow-related</code> flow is always
+        allowed and cannot be changed through an ACL.
+      </p>
+    </column>
+
+    <column name="direction">
+      <p>Direction of the traffic to which this rule should apply:</p>
+      <ul>
+        <li>
+          <code>from-lport</code>: Used to implement filters on traffic
+          arriving from a logical port.  These rules are applied to the
+          logical switch's ingress pipeline.
+        </li>
+        <li>
+          <code>to-lport</code>: Used to implement filters on traffic
+          forwarded to a logical port.  These rules are applied to the
+          logical switch's egress pipeline.
+        </li>
+      </ul>
     </column>
 
     <column name="match">
-      The packets that the ACL should match, in the same expression language
-      used for the <ref column="match" table="Logical_Flow"
-      db="OVN_Southbound"/> column in the OVN Southbound database's <ref
-      table="Logical_Flow" db="OVN_Southbound"/> table.  Match
-      <code>inport</code> and <code>outport</code> against names of logical
-      ports within <ref column="lswitch"/> to implement ingress and egress
-      ACLs, respectively.  In logical switches connected to logical routers,
-      the special port name <code>ROUTER</code> refers to the logical router
-      port.
+      <p>
+        The packets that the ACL should match, in the same expression
+        language used for the <ref column="match" table="Logical_Flow"
+        db="OVN_Southbound"/> column in the OVN Southbound database's
+        <ref table="Logical_Flow" db="OVN_Southbound"/> table.  The
+        <code>outport</code> logical port is only available in the
+        <code>to-lport</code> direction (the <code>inport</code> is
+        available in both directions).
+      </p>
+
+      <p>
+        By default all traffic is allowed.  When writing a more
+        restrictive policy, it is important to remember to allow flows
+        such as ARP and IPv6 neighbor discovery packets.
+      </p>
+
+      <p>
+        In logical switches connected to logical routers, the special
+        port name <code>ROUTER</code> refers to the logical router port.
+      </p>
     </column>
 
     <column name="action">
       <p>The action to take when the ACL rule matches:</p>
-      
       <ul>
         <li>
           <code>allow</code>: Forward the packet.
         <li>
           <code>reject</code>: Drop the packet, replying with a RST for TCP or
           ICMP unreachable message for other IP-based protocols.
+          <code>Not implemented--currently treated as drop</code>
         </li>
       </ul>
-
-      <p>
-       Only <code>allow</code> and <code>drop</code> are implemented:
-       <code>allow-related</code> is currently treated as <code>allow</code>,
-       and <code>reject</code> as <code>drop</code>.
-      </p>
     </column>
 
     <column name="log">
       <p>
-       If set to <code>true</code>, packets that match the ACL will trigger a
-       log message on the transport node or nodes that perform ACL processing.
-       Logging may be combined with any <ref column="action"/>.
+        If set to <code>true</code>, packets that match the ACL will trigger a
+        log message on the transport node or nodes that perform ACL processing.
+        Logging may be combined with any <ref column="action"/>.
       </p>
 
       <p>
-       Logging is not yet implemented.
+        Logging is not yet implemented.
       </p>
     </column>
 
     </column>
 
     <column name="ports">
-      The router's ports.  This is a set of weak references, so a <ref
-      table="Logical_Switch"/> must also refer to any given <ref
-      table="Logical_Router_Port"/> or it will automatically be deleted.
+      The router's ports.
     </column>
 
     <column name="default_gw">
     </p>
 
     <p>
-      A router port is always attached to a logical switch and to a logical
-      router.  The former attachment, which is enforced by the database schema,
-      can be identified by finding the <ref table="Logical_Switch"/> row whose
-      <ref column="router_port" table="Logical_Switch"/> column points to the
-      router port.  The latter attachment, which the database schema does not
-      enforce, can be identified by finding the <ref table="Logical_Router"/>
-      row whose <ref column="ports" table="Logical_Router"/> column includes
-      the router port.
+      Exactly one <ref table="Logical_Router"/> row must reference a given
+      logical router port.
     </p>
 
     <column name="name">
       The Ethernet address that belongs to this router port.
     </column>
 
+    <group title="Attachment">
+      <p>
+        A given router port serves one of two purposes:
+      </p>
+
+      <ul>
+        <li>
+          To attach a logical switch to a logical router.  A logical router
+          port of this type is referenced by exactly the <ref
+          column="router_port" table="Logical_Switch"/> column in exactly one
+          <ref table="Logical_Switch"/> row.  The <ref column="peer"/> column
+          is empty.
+        </li>
+
+        <li>
+          To connect one logical router to another.  This requires a pair of
+          logical router ports, each connected to a different router.  Each
+          router port in the pair specifies the other in its <ref
+          column="peer"/> column.  No <ref table="Logical_Switch"/> refers to
+          the router port.
+        </li>
+      </ul>
+
+      <column name="peer">
+        <p>
+          For a router port used to connect two logical routers, this
+          identifies the other router port in the pair.
+        </p>
+
+        <p>
+          For a router port attached to a logical switch, this column is empty.
+        </p>
+      </column>
+    </group>
+
     <group title="Common Columns">
       <column name="external_ids">
         See <em>External IDs</em> at the beginning of this document.