[ovs-dev] [ovn-controller-vtep V6 7/7] ovn-controller-vtep: Update related documentation.

Russell Bryant rbryant at redhat.com
Sun Aug 16 22:38:43 UTC 2015


Thanks for the docs!  Just some minor comments/questions ...

On 08/09/2015 10:50 PM, Alex Wang wrote:
> 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

It doesn't have to be running on the same host, right?

How about: The ovn-controller-vtep connected to this VTEP database ...

> +      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.

I'm not sure I understand this.  Do you mean multiple VTEP gateways can
use the same logical switch name?

> +    </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>

This part isn't implemented yet, right?  Maybe leave it out for now?  Or
at least clarify what happens today vs. how it might work in the future.

> +
> +    <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">
> 


-- 
Russell Bryant



More information about the dev mailing list