[ovs-dev] [ovn-controller-vtep V6 7/7] ovn-controller-vtep: Update related documentation.
Alex Wang
alexw at nicira.com
Mon Aug 17 02:33:53 UTC 2015
On Sun, Aug 16, 2015 at 3:38 PM, Russell Bryant <rbryant at redhat.com> wrote:
> 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 ...
>
>
Yeah, I adopted your suggestion,
> > + 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?
>
Exactly, how about just take words from your question and change that to
"since multiple VTEP gateways can attach to 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>
>
> 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.
>
>
Okay, I'll leave it out, since I'd like to add support for updating the
"Mcast_Macs_Remote" table, I'll keep the related documentation in
the previous bulletin,
Thanks,
Alex Wang,
> > +
> > + <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