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

[Darrell Ball]

Hi Russell

Thanks for your comments

Darrell




On 2/5/16, 12:23 PM, "Russell Bryant" <russell at 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