[ovs-dev] [ovn-controller-vtep V3 2/7] ovn-sb: Remove the "Gateway" table from the ovn-sb schema.

Alex Wang alexw at nicira.com
Wed Jul 15 19:09:21 UTC 2015


On Wed, Jul 15, 2015 at 11:22 AM, Russell Bryant <rbryant at redhat.com> wrote:

> On 07/13/2015 11:22 PM, Alex Wang wrote:
> > In a gateway like the VTEP L2 gateway, physical vlans belonging to
> > the same logical network form a "logical switch".  Each logical switch
> > has a dedicated tunnel key and will keep records of all MACs learned
> > from the owned vlans.  So user can just send packet to a "logical
> > switch" and the gateway will figure out the output port and vlan tag
> > automatically.
> >
> > Therefore, it is not really necessary to keep record of the vlan map
> > for each gateway physical port in the OVN_Southbound database using
> > "gateway_ports".
> >
> > Thusly, this commit removes the "Gateway" table from the OVN_Southbound
> > database.  In the "Chassis" table, the "gateway_ports" column is replaced
> > by "logical_switches" column which maps the logical switch name in the
> > gateway to a logical port name that exists in the OVN_Northbound
> database's
> > "Logical_Port" table.
> >
> > Signed-off-by: Alex Wang <alexw at nicira.com>
>
> I think this makes sense to me.  I wonder if calling it
> "logical_switches" could be confusing with the logical switch in OVN
> Northbound.  Maybe "vtep_logical_switches" would clarify?
>
>

I'm not sure, if we may need the same map for non-vtep switch (e.g. dpdk
switch).  but I'm also fine with defining it more specific as suggested,



> To make sure I understand correctly ...
>
> 1) ovn-controller-vtep will register itself in the Chassis table.  It
> will populate the Chassis "logical_switches" with a list of the VTEP
> switch's logical switches and associated auto-generated logical port names.
>


Yes,



> 2) A management system will update OVN_Northbound with a logical port
> with a special name that indicates that it's associated with a given
> VTEP logical switch.
>
>
Yes


> 3) ovn-northd creates a Binding for this logical port just like a normal
> port and assigns it a tunnel key.
>
> 4) ovn-controller-vtep will see this Binding and assign this tunnel key
> to the logical switch via the VTEP schema.
>
> Is this how the tunnel key is decided on to reach a given vtep logical
> switch?  If so, where is #4 done?  or did I misunderstand the flow?
>


I think your understanding is correct,

And Ben's upcoming change will make northd assign a tunnel key per (ovn-
nb) logical switch.  And ovn-controller-vtep is responsible for updating the
tunnel key to the (vtep db) logical switch.



> Also, what do you think about my proposal for using "type" and "options"
> fields on logical ports in OVN_Northbound instead of a special port
> name?  If we went this route, you don't need "logical_switches" to be a
> smap, it can just be a list of logical switch names.  Creating a
> connection in OVN northbound would be something like:
>
>   Logical_Port
>     name: <anything>
>     type: vtep
>     options:
>        vtep_physical_switch: <...>
>        vtep_logical_switch: <...>
>
>

One thing I see missing is that: multiple vtep physical switches (supported
by
the same vtep db) could connect to the same vtep logical switch...   In
that
case, logical switch name can no longer uniquely identify a connection of
'a vtep physical switch to a vtep logical switch'...  That's why I use the
combination of pswitch_name+lswitch_name.

With you suggestion, first, the logical port name in ovn-nb can be
duplicated.
And if that is allowed, we need to pass the "options" down to ovn-sb
Binding table to uniquely binding the vtep lport to vtep chassis.


Thanks,
Alex Wang,



> --
> Russell Bryant
>



More information about the dev mailing list