Hi Russell Thanks for your comments
Darrell On 2/5/16, 12:23 PM, "Russell Bryant" <russ...@ovn.org> wrote: >On 01/29/2016 09:36 PM, Darrell Lu wrote: >> The following is a proposal regarding how to allow logical >> and physical endpoint contexts for OVN to stay separated, from >> a CMS POV. >> >> A logical endpoint has the form: ls1-port1. >> A physical endpoint has the general form: >> chassis/physical port or location on chassis/encapsulation. >> >> Some advantages for cleanly separating logical and physical >> layers are: >> >> 1) Logical and physical domains can be managed separately; for >> example, by different companies or business units, with minimal >> interaction overhead. >> >> 2)The physical layer details can change without needing to >> change the logical layer; for example, a physical endpoint >> vlan can change without needing to change the logical layer, >> which in OVN resides in the NB DB. >> The physical endpoint encapsulations can even change in future, >> without needing to update the NB DB supported options and/or >> churning the NB DB. >> >> 3) The logical configuration remains simple in that it just needs >> to concern itself with tasks such linking users to services, >> without too much concern about where the services >> or users are presently located. >> >> >> A physical topology CMS or sub-component of a CMS can be >> used to configure physical endpoints in the SB DB directly, >> bypassing the NB DB and northd processing. > >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. 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 > >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 > >Thanks, > >-- >Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
