On Sun, Aug 16, 2015 at 3:38 PM, Russell Bryant <rbry...@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 <al...@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 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
