[ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical endpoint separation proposal

Russell Bryant russell at ovn.org
Mon Feb 8 20:38:33 UTC 2016


On 02/08/2016 12:05 PM, Darrell Ball wrote:
> On 2/5/16, 12:23 PM, "Russell Bryant" <russell at 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.

>> 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.

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?

I'm still not clear on what's happening in between the northbound
programming with the options removed and having gateway connectivity to
a network.

-- 
Russell Bryant



More information about the dev mailing list