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

Russell Bryant russell at ovn.org
Thu Feb 11 20:20:16 UTC 2016


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" <russell at ovn.org> wrote:
> 
>> 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.

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



More information about the dev mailing list