[ovs-dev] [PATCH v4] vtep: Support per-tunnel tunnel key in schema.

Ben Pfaff blp at ovn.org
Fri Feb 5 20:54:57 UTC 2016


From: Ofer Ben Yacov <ofer.benyacov at gmail.com>

Currently the scenario of single logical bridge that use multiple locators
with different tunnel key on each of the locators is not supported.
In order to support much more flexibility in the tunnel settings, we need
to add tunnel key column to the Physical_Locator table.

This patch is needed to support the usage of neutron L2GW as an inter-cloud
gateway. The tunnel key that is set in the logical bridge will be used
'internally' to connect the L2GW to the compute hosts and the key that
is set in the physical locator will be used to connect the L2GW to a
remote L2GW to form a tunnel between 2 clouds. In this case, the
'external' connection will use single 'dst_ip' on all the locators with
different tunnel key for each L2 domain.

The Neutron spec is available here:
	https://review.openstack.org/#/c/270786/
The new code depend on the ability to use different keys in multiple
tunnels in the same logical switch.

Signed-off-by: Ofer Ben-Yacov <ofer.benyacov at gmail.com>
[blp at ovn.org added and clarified documentation]
Signed-off-by: Ben Pfaff <blp at ovn.org>
---
 vtep/vtep.ovsschema |  9 +++++----
 vtep/vtep.xml       | 51 ++++++++++++++++++++++++++++++---------------------
 2 files changed, 35 insertions(+), 25 deletions(-)

diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
index 1375173..cf3538f 100644
--- a/vtep/vtep.ovsschema
+++ b/vtep/vtep.ovsschema
@@ -1,6 +1,6 @@
 {
   "name": "hardware_vtep",
-  "cksum": "2177247725 10499",
+  "cksum": "1621458335 10585",
   "tables": {
     "Global": {
       "columns": {
@@ -188,8 +188,9 @@
               "enum": ["set", ["vxlan_over_ipv4"]],
               "type": "string"}},
           "mutable": false},
-        "dst_ip": {"type": "string", "mutable": false}},
-      "indexes": [["encapsulation_type", "dst_ip"]]},
+        "dst_ip": {"type": "string", "mutable": false},
+        "tunnel_key": {"type": {"key": "integer", "min": 0, "max": 1}}},
+      "indexes": [["encapsulation_type", "dst_ip", "tunnel_key"]]},
     "ACL_entry": {
       "columns": {
         "sequence": {"type": "integer"},
@@ -283,4 +284,4 @@
           "ephemeral": true}},
       "indexes": [["target"]],
       "isRoot": false}},
-  "version": "1.4.1"}
+  "version": "1.5.0"}
diff --git a/vtep/vtep.xml b/vtep/vtep.xml
index 6c49e06..7112111 100644
--- a/vtep/vtep.xml
+++ b/vtep/vtep.xml
@@ -689,9 +689,10 @@
         </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>
@@ -993,24 +994,17 @@
     </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">
@@ -1029,6 +1023,21 @@
       </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>
-- 
2.1.3




More information about the dev mailing list