On Wed, Jul 15, 2015 at 11:22 AM, Russell Bryant <rbry...@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 <al...@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 > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
