vtep: Add error messages for logical router support
[cascardo/ovs.git] / vtep / vtep.xml
index 8ca9f26..b1befce 100644 (file)
@@ -5,7 +5,7 @@
     physical ports into logical switches maintained by a network
     virtualization controller such as NSX.
   </p>
-  
+
   <p>Glossary:</p>
 
   <dl>
@@ -29,7 +29,7 @@
     <dd>
       Virtual Routing and Forwarding instance.
     </dd>
- </dl>
 </dl>
 
   <table name="Global" title="Top-level configuration.">
     Top-level configuration for a hardware VTEP.  There must be
       </p>
 
       <column name="other_config" key="dscp"
-                type='{"type": "integer"}'>
+              type='{"type": "integer"}'>
         The Differentiated Service Code Point (DSCP) is specified using 6 bits
         in the Type of Service (TOS) field in the IP header. DSCP provides a
         mechanism to classify the network traffic and provide Quality of
       <column name="name">
         Symbolic name for the switch, such as its hostname.
       </column>
-      
+
       <column name="description">
         An extended description for the switch, such as its switch login
         banner.
         requested by the NVC due to lack of resources.
       </column>
 
+      <column name="switch_fault_status" key="lr_switch_bindings_fault">
+        Indicates that the switch has been unable to create the logical router
+        interfaces requested by the NVC due to conflicting configurations or a
+        lack of hardware resources.
+      </column>
+
+      <column name="switch_fault_status" key="lr_static_routes_fault">
+        Indicates that the switch has been unable to create the static routes
+        requested by the NVC due to conflicting configurations or a lack of
+        hardware resources.
+      </column>
+
+      <column name="switch_fault_status" key="lr_creation_fault">
+        Indicates that the switch has been unable to create the logical router
+        requested by the NVC due to conflicting configurations or a lack of
+        hardware resources.
+      </column>
+
+      <column name="switch_fault_status" key="lr_support_fault">
+        Indicates that the switch does not support logical routing.
+      </column>
+
       <column name="switch_fault_status" key="unspecified_fault">
         Indicates that an error has occurred in the switch but that no
         more specific information is available.
       </p>
 
       <p>
-        In most cases the BFD peer of a hardware VTEP will be an Open vSwitch
+        In many cases the BFD peer of a hardware VTEP will be an Open vSwitch
         instance. The Open vSwitch implementation of BFD aims to comply
         faithfully with the requirements put forth in RFC 5880.  Open vSwitch
         does not implement the optional Authentication or ``Echo Mode''
         </p>
 
         <column name="bfd_params" key="enable" type='{"type": "boolean"}'>
-          True to enable BFD on this tunnel.
-          The default is False.
+          True to enable BFD on this <ref table="Tunnel"/>.  If not
+          specified, BFD will not be enabled by default.
         </column>
 
         <column name="bfd_params" key="min_rx"
 
         <column name="bfd_params" key="decay_min_rx" type='{"type": "integer"}'>
           An alternate receive interval, in milliseconds, that must be greater
-          than or equal to <ref column="bfd" key="min_rx"/>.  The
-          implementation switches from <ref column="bfd" key="min_rx"/> to <ref
-          column="bfd" key="decay_min_rx"/> when there is no obvious incoming
-          data traffic at the interface, to reduce the CPU and bandwidth cost
-          of monitoring an idle interface.  This feature may be disabled by
-          setting a value of 0.  This feature is reset whenever <ref
-          column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/>
-          changes.
+          than or equal to <ref column="bfd_params" key="min_rx"/>.  The
+          implementation should switch from <ref column="bfd_params" key="min_rx"/>
+          to <ref column="bfd_params" key="decay_min_rx"/> when there is no obvious
+          incoming data traffic at the tunnel, to reduce the CPU and bandwidth
+          cost of monitoring an idle tunnel.  This feature may be disabled by
+          setting a value of 0.  This feature is reset whenever
+          <ref column="bfd_params" key="decay_min_rx"/> or
+          <ref column="bfd_params" key="min_rx"/> changes.
         </column>
 
         <column name="bfd_params" key="forwarding_if_rx" type='{"type": "boolean"}'>
-          True to consider the interface capable of packet I/O as long as it
-          continues to receive any packets (not just BFD packets).  This
-          prevents link congestion that causes consecutive BFD control packets
-          to be lost from marking the interface down.
+          When <code>true</code>, traffic received on the <ref table="Tunnel"/>
+          is used to indicate the capability of packet I/O.
+          BFD control packets are still transmitted and received. At least one
+          BFD control packet must be received every
+          100 * <ref column="bfd_params" key="min_rx"/> amount of time.
+          Otherwise, even if traffic is received, the
+          <ref column="bfd_params" key="forwarding"/> will be <code>false</code>.
         </column>
 
         <column name="bfd_params" key="cpath_down" type='{"type": "boolean"}'>
 
       </group>
 
-     <group title="BFD Status">
-      <p>
-        The VTEP sets key-value pairs in the <ref column="bfd_status"/>
-        column to report the status of BFD on this tunnel.  When BFD is
-        not enabled, with <ref column="bfd_params" key="enable"/>, the
-        HSC clears all key-value pairs from <ref column="bfd_status"/>.
-      </p>
+      <group title="BFD Status">
+        <p>
+          The VTEP sets key-value pairs in the <ref column="bfd_status"/>
+          column to report the status of BFD on this tunnel.  When BFD is
+          not enabled, with <ref column="bfd_params" key="enable"/>, the
+          HSC clears all key-value pairs from <ref column="bfd_status"/>.
+        </p>
 
-      <column name="bfd_status" key="enabled"
-        type='{"type": "boolean"}'>
-        Set to true if the BFD session has been successfully
-        enabled. Set to false if the VTEP cannot support BFD or has
-        insufficient resources to enable BFD on this tunnel. The NVC
-        will disable the BFD monitoring on the other side of the tunnel
-        once this value is set to false.
-      </column>
+        <column name="bfd_status" key="enabled" type='{"type": "boolean"}'>
+          Set to true if the BFD session has been successfully enabled.
+          Set to false if the VTEP cannot support BFD or has insufficient
+          resources to enable BFD on this tunnel. The NVC will disable
+          the BFD monitoring on the other side of the tunnel once this
+          value is set to false.
+        </column>
 
-      <column name="bfd_status" key="state"
-        type='{"type": "string",
+        <column name="bfd_status" key="state"
+                type='{"type": "string",
               "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
-        Reports the state of the BFD session.  The BFD session is fully
-        healthy and negotiated if <code>UP</code>.
-      </column>
+          Reports the state of the BFD session.  The BFD session is fully
+          healthy and negotiated if <code>UP</code>.
+        </column>
 
-      <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'>
-        Reports whether the BFD session believes this tunnel
-        may be used to forward traffic.  Typically this means the local session
-        is signaling <code>UP</code>, and the remote system isn't signaling a
-        problem such as concatenated path down.
-      </column>
+        <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'>
+          Reports whether the BFD session believes this  <ref table="Tunnel"/>
+          may be used to forward traffic.  Typically this means the local session
+          is signaling <code>UP</code>, and the remote system isn't signaling a
+          problem such as concatenated path down.
+        </column>
 
-      <column name="bfd_status" key="diagnostic">
-        In case of a problem, set to an error message that reports what the
-        local BFD session thinks is wrong.  The error messages are defined
-        in section 4.1 of [RFC 5880].
-      </column>
+        <column name="bfd_status" key="diagnostic">
+          A diagnostic code specifying the local system's reason for the
+          last change in session state. The error messages are defined in
+          section 4.1 of [RFC 5880].
+        </column>
 
-      <column name="bfd_status" key="remote_state"
-        type='{"type": "string",
+       <column name="bfd_status" key="remote_state"
+                type='{"type": "string",
               "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
-        Reports the state of the remote endpoint's BFD session.
-      </column>
+          Reports the state of the remote endpoint's BFD session.
+        </column>
 
-      <column name="bfd_status" key="remote_diagnostic">
-        In case of a problem, set to an error message that reports what the
-        remote endpoint's BFD session thinks is wrong.  The error messages
-        are defined in section 4.1 of [RFC 5880].
-      </column>
+        <column name="bfd_status" key="remote_diagnostic">
+          A diagnostic code specifying the remote system's reason for the
+          last change in session state. The error messages are defined in
+          section 4.1 of [RFC 5880].
+        </column>
 
-      <column name="bfd_status" key="info">
-        A short message providing further information about the BFD status
-        (possibly including reasons why BFD could not be enabled).
-      </column>
+        <column name="bfd_status" key="info">
+          A short message providing further information about the BFD status
+          (possibly including reasons why BFD could not be enabled).
+        </column>
       </group>
     </group>
   </table>
         </p>
 
         <p>
-          For <code>vxlan_over_ipv4</code> encapsulation, this column
-          is the VXLAN VNI that identifies a logical switch.  It must
-          be in the range 0 to 16,777,215.
+          For <code>vxlan_over_ipv4</code> encapsulation, when the tunnel key
+          per <ref table="Logical_Switch"/> model is in use, this column is the
+          VXLAN VNI that identifies a logical switch.  It must be in the range
+          0 to 16,777,215.
         </p>
       </column>
     </group>
       <column name="name">
         Symbolic name for the logical switch.
       </column>
-      
+
       <column name="description">
         An extended description for the logical switch, such as its switch
         login banner.
 
   </table>
 
- <table name="Ucast_Macs_Remote" title="Unicast MACs (remote)">
 <table name="Ucast_Macs_Remote" title="Unicast MACs (remote)">
     <p>
       Mapping of unicast MAC addresses to tunnels (physical
       locators). This table is written by the NVC, so it contains the
 
     <column name="MAC">
       <p>
-        A MAC address that has been learned by the VTEP. 
+        A MAC address that has been learned by the VTEP.
       </p>
       <p>
         The keyword <code>unknown-dst</code> is used as a special
   <table name="Logical_Router" title="A logical L3 router.">
     <p>
       A logical router, or VRF. A logical router may be connected to one or more
-      logical switches. Subnet addresses and interface addresses may be configured on the 
+      logical switches. Subnet addresses and interface addresses may be configured on the
       interfaces.
     </p>
-    
+
     <column name="switch_binding">
       Maps from an IPv4 or IPv6 address prefix in CIDR notation to a
       logical switch. Multiple prefixes may map to the same switch. By
       table="Physical_Locator"/> records.''
     </p>
 
-    <column name="locators"/>    
+    <column name="locators"/>
   </table>
 
   <table name="Physical_Locator">
     </p>
 
     <p>
-      For the <code>vxlan_over_ipv4</code> encapsulation, the only
-      encapsulation defined so far, all endpoints associated with a given <ref
-      table="Logical_Switch"/> must use a common tunnel key, which is carried
-      in the <ref table="Logical_Switch" column="tunnel_key"/> column of <ref
-      table="Logical_Switch"/>.
-    </p>
-
-    <p>
-      For some encapsulations yet to be defined, we expect <ref
-      table="Physical_Locator"/> to identify both an endpoint and a tunnel key.
-      When the first such encapsulation is defined, we expect to add a
-      ``tunnel_key'' column to <ref table="Physical_Locator"/> to allow the
-      tunnel key to be defined.
-    </p>
-
-    <p>
-      See the ``Per Logical-Switch Tunnel Key'' section in the <ref
-      table="Logical_Switch"/> table for further discussion of the model.
+      The <code>vxlan_over_ipv4</code> encapsulation, the only encapsulation
+      defined so far, can use either tunnel key model described in the ``Per
+      Logical-Switch Tunnel Key'' section in the <ref table="Logical_Switch"/>
+      table.  When the tunnel key per <ref table="Logical_Switch"/> model is in
+      use, the <ref table="Logical_Switch" column="tunnel_key"/> column in the
+      <ref table="Logical_Switch"/> table is filled with a VNI and the <ref
+      column="tunnel_key"/> column in this table is empty; in the
+      key-per-tunnel model, the opposite is true.  The former model is older,
+      and thus likely to be more widely supported.  See the ``Per
+      Logical-Switch Tunnel Key'' section in the <ref table="Logical_Switch"/>
+      table for further discussion of the model.
     </p>
 
     <column name="encapsulation_type">
       </p>
     </column>
 
+    <column name="tunnel_key">
+      <p>
+        This column is used only in the tunnel key per <ref
+        table="Logical_Switch"/>+<ref table="Physical_Locator"/> model (see
+        above).
+      </p>
+
+      <p>
+        For <code>vxlan_over_ipv4</code> encapsulation, when the <ref
+        table="Logical_Switch"/>+<ref table="Physical_Locator"/> model is in
+        use, this column is the VXLAN VNI.  It must be in the range 0 to
+        16,777,215.
+      </p>
+    </column>
+
   </table>
   <table name="ACL_entry">
     <p>
           <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
         </p>
       </column>
-            <column name="ethertype">
+      <column name="ethertype">
         <p>
           Ethertype in hexadecimal, in the form
           <var>0xAAAA</var>