[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