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

[Darrell Ball]

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




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