[ovs-dev] [ovn-controller-vtep V6 7/7] ovn-controller-vtep: Update related documentation.
Alex Wang
alexw at nicira.com
Mon Aug 10 02:50:47 UTC 2015
This commit conducts the following documentation changes:
* add a description in ovn-architecture manual for
the life cycle about VTEP gateway.
* add TODOs related to ovn-controller-vtep.
* refine the ovn-sb, ovn-nb schema manual to require
logical 'port' type and 'options' configuration.
Signed-off-by: Alex Wang <alexw at nicira.com>
---
V5->V6:
- add description in ovn-architecture.
V5: new patch.
---
ovn/TODO | 21 ++++++++++
ovn/ovn-architecture.7.xml | 99 ++++++++++++++++++++++++++++++++++++++++++++
ovn/ovn-nb.xml | 31 +++++++++++---
ovn/ovn-sb.xml | 41 ++++++++++++++----
4 files changed, 179 insertions(+), 13 deletions(-)
diff --git a/ovn/TODO b/ovn/TODO
index 356b3ba..56cac87 100644
--- a/ovn/TODO
+++ b/ovn/TODO
@@ -80,3 +80,24 @@
So far, both ovn-controller and ovn-controller-vtep only allow
chassis to have one tunnel encapsulation entry. We should extend
the implementation to support multiple tunnel encapsulations.
+
+** Update learned MAC addresses from VTEP to OVN
+
+ The VTEP gateway stores all MAC addresses learned from its
+ physical interfaces in the 'Ucast_Macs_Local' and the
+ 'Mcast_Macs_Local' tables. ovn-controller-vtep should be
+ able to update those information back to ovn-sb database,
+ so that other chassis knows where to send packets destined
+ to the extended external network instead of broadcasting.
+
+** Translate ovn-sb Multicast_Group table into VTEP config
+
+ The ovn-controller-vtep daemon should be able to translate
+ the Multicast_Group table entry in ovn-sb database into
+ Mcast_Macs_Remote table configuration in VTEP database.
+
+* Use BFD as tunnel monitor.
+
+ Both ovn-controller and ovn-contorller-vtep should use BFD to
+ monitor the tunnel liveness. Both ovs-vswitchd schema and
+ VTEP schema supports BFD.
\ No newline at end of file
diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml
index 1b537f9..5e020ac 100644
--- a/ovn/ovn-architecture.7.xml
+++ b/ovn/ovn-architecture.7.xml
@@ -797,6 +797,105 @@
</li>
</ol>
+ <h2>Life Cycle of a VTEP gateway</h2>
+
+ <p>
+ A gateway is a chassis that forwards traffic between the OVN-managed
+ part of a logical network and a physical VLAN, extending a
+ tunnel-based logical network into a physical network.
+ </p>
+
+ <p>
+ The steps below refer often to details of the OVN and VTEP database
+ schemas. Please see <code>ovn-sb</code>(5), <code>ovn-nb</code>(5)
+ and <code>vtep</code>(5), respectively, for the full story on these
+ databases.
+ </p>
+
+ <ol>
+ <li>
+ A VTEP gateway's life cycle begins with the administrator registering
+ the VTEP gateway as a <code>Physical_Switch</code> table entry in the
+ <code>VTEP</code> database. The <code>ovn-controller-vtep</code>,
+ running on the same host as <code>VTEP</code> database, will recognize
+ the new VTEP gateway and create a new <code>Chassis</code> table entry
+ for it in the <code>OVN_Southbound</code> database.
+ </li>
+
+ <li>
+ The administrator can then create new <code>Logical_Switch</code>
+ table entry, and bind particular vlan on VTEP gateway's port to
+ any VTEP logical switch. Once a VTEP logical switch is bound to
+ a VTEP gateway, the <code>ovn-controller-vtep</code> will detect
+ it and add its name to the <var>vtep_logical_switches</var>
+ column of the <code>Chassis</code> table in the <code>
+ OVN_Southbound</code> database. Note, the <var>tunnel_key</var>
+ column of VTEP logical switch is not filled at creation. The
+ <code>ovn-controller-vtep</code> will set the column when the
+ correponding vtep logical switch is bound to an OVN logical network.
+ </li>
+
+ <li>
+ Now, the administrator can use the CMS to add VTEP logical switch
+ to the OVN logical network. To do that, the CMS must first create a
+ new <code>Logical_Port</code> table entry in the <code>
+ OVN_Northbound</code> database. Then, the <var>type</var> column
+ of this entry must be set to "vtep". Next, the <var>
+ vtep-logical-switch</var> and <var>vtep-physical-switch</var> keys
+ in the <var>options</var> column must also be specified, since
+ multiple VTEP gateways can be bound the same VTEP logical switch.
+ </li>
+
+ <li>
+ The newly created logical port in the <code>OVN_Northbound</code>
+ database and its configuration will be passed down to the <code>
+ OVN_Southbound</code> database as a new <code>Port_Binding</code>
+ table entry. The <code>ovn-controller-vtep</code> will recognize the
+ change and bind the logical port to the corresponding VTEP gateway
+ chassis. Configuration of binding same VTEP logical switch to
+ different OVN logical networks is not allowed and warning will be
+ generated in the log.
+ </li>
+
+ <li>
+ Beside binding to the VTEP gateway chassis, the <code>
+ ovn-controller-vtep</code> will update the <var>tunnel_key</var>
+ column of the VTEP logical switch to the corresponding <code>
+ Datapath_Binding</code> table entry's <var>tunnel_key</var> for the
+ bound OVN logical network.
+ </li>
+
+ <li>
+ Next, the <code>ovn-controller-vtep</code> will keep reacting to the
+ <code>Port_Binding</code> table and the <code>Multicast_Group</code>
+ table configuration change in the <code>OVN_Northbound</code> database,
+ and updating the <code>Ucast_Macs_Remote</code> table and the <code>
+ Mcast_Macs_Remote</code> table in the <code>VTEP</code> database,
+ respectively. This allows the VTEP gateway understand where to
+ forward the traffic coming from the extended external network.
+ </li>
+
+ <li>
+ Meanwhile, the <code>ovn-controller-vtep</code> will keep reacting to
+ the <code>Ucast_Macs_Local</code> table and the <code>
+ Mcast_Macs_Local</code> table changes for each VTEP logical switch
+ in the <code>VTEP</code> database, and updating the corresponding
+ <code>Port_Binding</code> table and the <code>Multicast_Group</code>
+ table entries in the <code>OVN_Northbound</code> database. This
+ allows other <code>ovn-controller</code> understand where to send
+ the traffic to the extended external network, instead of always
+ broadcasting it.
+ </li>
+
+ <li>
+ Eventually, the VTEP gateway's life cycle ends when the administrator
+ unregisters the VTEP gateway from the <code>VTEP</code> database.
+ The <code>ovn-controller-vtep</code> will recognized the event and
+ remove all related configurations in the <code>OVN_Southbound</code>
+ database.
+ </li>
+ </ol>
+
<h1>Design Decisions</h1>
<h2>Tunnel Encapsulations</h2>
diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml
index ade8164..5bb9265 100644
--- a/ovn/ovn-nb.xml
+++ b/ovn/ovn-nb.xml
@@ -111,18 +111,37 @@
<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. Besides, the following types are
+ defined:
</p>
- <p>
- There are no other logical port types implemented yet.
- </p>
+ <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"/>:vtep_physical_switch
+ and <ref column="options" table="Logical_Port"/>:vtep_logical_switch
+ 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>
+
+ <dl>
+ <dt><code>vtep_physical_switch</code></dt>
+ <dd>The name of the VTEP gateway.</dd>
+ </dl>
+
+ <dl>
+ <dt><code>vtep_logical_switch</code></dt>
+ <dd>A logical switch name connected by the VTEP gateway.</dd>
+ </dl>
</column>
<column name="parent_name">
diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml
index 7defad9..fd6d0ff 100644
--- a/ovn/ovn-sb.xml
+++ b/ovn/ovn-sb.xml
@@ -172,7 +172,13 @@
<column name="vtep_logical_switches">
Stores all vtep logical switch names connected by this gateway
- chassis.
+ chassis. The <ref table="Port_Binding"/> table entry with
+ <ref column="options" table="Port_Binding"/>:vtep_physical_switch
+ equal <ref table="Chassis"/> <ref column="name" table="Chassis"/>,
+ and <ref column="options" table="Port_Binding"/>:vtep_logical_switch
+ value in <ref table="Chassis"/>
+ <ref column="vtep_logical_switches" table="Chassis"/>, will be
+ associated with this <ref table="Chassis"/>.
</column>
</group>
</table>
@@ -883,18 +889,39 @@
<column name="type">
<p>
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. Besides, the following types are
+ defined:
</p>
- <p>
- There are no other logical port types implemented yet.
- </p>
+ <dl>
+ <dt><code>vtep</code></dt>
+ <dd>A port to a logical switch on a VTEP gateway chassis. In order
+ to get this port correctly recognized by the ovn controller, the
+ <ref column="options" table="Port_Binding"/>:vtep_physical_switch
+ and <ref column="options" table="Port_Binding"/>:vtep_logical_switch
+ 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>
+
+ <dl>
+ <dt><code>vtep_physical_switch</code></dt>
+ <dd>The <ref column="name" table="Chassis"/> of the VTEP gateway
+ chassis.</dd>
+ </dl>
+
+ <dl>
+ <dt><code>vtep_logical_switch</code></dt>
+ <dd>A logical switch name in VTEP gateway chassis's
+ <ref column="vtep_logical_switches" table="Chassis"/>.</dd>
+ </dl>
</column>
<column name="tunnel_key">
--
1.7.9.5
More information about the dev
mailing list