[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