On 02/10/2016 09:56 PM, Darrell Ball wrote: > Hi Russell > > Please see inline > > Thanks Darrell > > > > On 2/8/16, 12:38 PM, "Russell Bryant" <russ...@ovn.org> wrote: > >> On 02/08/2016 12:05 PM, Darrell Ball wrote: >>> On 2/5/16, 12:23 PM, "Russell Bryant" <russ...@ovn.org> wrote: >>>> I agree with this sort of separation in principle. Some specific >>>> examples would help me understand the proposal, though. You mention >>>> that this applies to both localnet and gateway cases. Can we lay out >>>> some clear workflows before and after the proposed changes? >>>> >>>> The simplest localnet example would be connecting a single VM to a >>>> physical network locally attached to a hypervisor. >>>> >>>> On the hypervisor running, ovn-controller, we set: >>>> >>>> $ ovs-vsctl set open . \ >>>> > external-ids:ovn-bridge-mappings=physnet1:br-eth1 >>>> >>>> Then, we set up the logical connectivity with: >>>> >>>> $ ovn-nbctl lswitch-add provnet1 >>>> >>>> $ ovn-nbctl lport-add provnet1 provnet1-lp1 >>>> $ ovn-nbctl lport-set-addresses provnet1-lp1 $MAC >>>> $ ovn-nbctl lport-set-port-security provnet1-lp1 $MAC >>>> >>>> $ ovn-nbctl lport-add provnet1 provnet1-physnet1 >>>> $ ovn-nbctl lport-set-addresses provnet1-physnet1 unknown >>>> $ ovn-nbctl lport-set-type provnet1-physnet1 localnet >>>> $ ovn-nbctl lport-set-options provnet1-physnet1 \ >>>> > network_name=physnet1 >>>> >>>> Then we can create the VIF on the hypervisor like usual. >>>> >>>> How does your proposal modify the workflow for this use case? >>> >>> Localnet case: The NB programming is unchanged, as intended. >>> >>> The SB programming using sb-ctl in lieu of CMS might be of >>> the form below. >> >> In this case, the CMS is only interfacing with the NB database. >> >>> This example assumes that we use the legacy endpoint type of >>> single_vlan and vlan 42 is used on chassis_port_0 on chassis_only >>> (which is our HV in this example). >>> >>> ovn-sbctl phys-endpt-add endpt_0 chassis_only chassis_port_0 single_vlan >>> 42 42 >>> >>> >>> ovn-sbctl lport-bind-phys-endpt provnet1-1-physnet1 endpt_0 >> >> I'm sorry if I'm being dense, but I'm afraid that I don't understand >> what this is replacing.
Note the above question. >> >>>> It would be nice to see the same sort of thing for gateways. The >>>> OpenStack driver already has code for the current vtep gateway >>>> integration. We set vtep_logical_switch and vtep_physical_switch on a >>>> logical port. What new workflow would we need to implement? >>> >>> >>> Gateway case: Consider ls0-port2 is a logical endpt on a gateway >>> >>> >>> ovn-nbctl lswitch-add ls0 >>> . >>> . >>> ovn-nbctl lport-add ls0 ls0-port2 >>> . >>> . >>> ovn-nbctl lport-set-addresses ls0-port2 52:54:00:f3:1c:c6 >>> . >>> . >>> ovn-nbctl lport-set-type ls0-port2 vtep >>> >>> >>> The NB programming lport-set-options, of the form: >>> “ovn-nbctl lport-set-options ls0-port2 vtep-physical-switch=br-int >>> vtep-logical-switch=ls0” >>> could be omitted and the same information could be derived from >>> other logical/physical binding. SB programming semantics, assuming that we >>> use >>> the legacy endpoint type and vlan 42 is used on chassis_port_0 on chassis_0 >>> (a gateway): >>> >>> >>> ovn-sbctl phys-endpt-add endpt_0 chassis_0 chassis_port_0 single_vlan 42 >>> 42 >>> >>> >>> ovn-sbctl lport-bind-phys-endpt ls0-port2 endpt_0 >> >> Is this right? >> >> 1) We're dropping the use of vtep-physical-switch and >> vtep-logical-switch options and instead getting the same information >>from logical-to-physical mappings in the southbound database. > > That’s the proposal > The logical port association to > 1) vtep Physical switch, can be derived from the port_binding/chassis tables > in the SB DB > 2) vtep logical switch, can come down to the SB DB via information in the > NB DB Logical Switch/Logical Port Tables > > >> >> 2) (I'm less sure on this part) We're replacing direct management of the >> hardware_vtep schema with defining endpoings in the physical endpoint >> table in OVN's southbound db? > > > For SW gateway, we don’t plan to support the hardware_vtep schema and use a > common code path b/w gateway and HV transport nodes, as much as possible. > Hence the SB DB is one option > to house the physical endpt table which is closely associated with the port > binding table. > The gateway or gateway pair/cluster supports the overall network. Are you planning on dropping hardware_vtep support? Are there two separate worksflows (software gateways vs hardware_vtep)? If you think it'd be easier to just proceed with your implementation and then it will be easier to understand, that's fine with me. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
