Darrell,
Thanks for your replies.
A few more questions for clarification.
You said:
>> There are multiple phys_endpts, one per chassis
>> chassis and chassis_port are set per chassis
>> Each localnet port on a chassis is bound to a phys_endpt on that chassis
In your earlier reply to Russell, your example:
>> ovn-sbctl lport-bind-phys-endpt provnet1-1-physnet1 endpt_0
If the command is onv-sbctl, how do you apply this per chassis?
Can you have multiple "ovn-sbctl lport-bind-phys-endpt" commands for the same
logical port?
If so, would you leave chassis in the port binding empty?
Why is the logical port name in this example "provnet1-1-physnet1" when the
logical port was defined earlier as "provnet1-physnet1"?
Was this intentional or a typo?
Mickey
-----Darrell Ball <db...@vmware.com> wrote: -----
To: Mickey Spiegel/San Jose/IBM@IBMUS
From: Darrell Ball <db...@vmware.com>
Date: 02/17/2016 07:47PM
Cc: Russell Bryant <russ...@ovn.org>, Darrell Lu <dlu...@gmail.com>,
"dev@openvswitch.org" <dev@openvswitch.org>
Subject: Re: [ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical endpoint
separation proposal
Hi Mickey
Thanks for your questions/comments
Darrell
From: Mickey Spiegel <emspi...@us.ibm.com>
Date: Tuesday, February 16, 2016 at 2:32 PM
To: Darrel Ball <db...@vmware.com>
Cc: Russell Bryant <russ...@ovn.org>, Darrell Lu <dlu...@gmail.com>,
"dev@openvswitch.org" <dev@openvswitch.org>
Subject: Re: [ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical endpoint
separation proposal
Darrell,
Just catching up on this thread. A few things are still unclear.
The example that you gave bound the one "localnet" logical port to one
physical endpoint. Perhaps this is what you are intending for the L3 gateway
case (still waiting for that proposal).
In existing OVN, VMs can connect directly to provider networks, requiring each
"localnet" logical port to be instantiated on each ovn-controller, i.e. there
are multiple chassis/chassis-port bindings, each one done locally on each
hypervisor based on local ovn-bridge-mapping configuration.
Does your proposal support this case?
If so, which of the following do you do? The chassis and chassis_port
columns are empty. On each hypervisor, ovn-bridge-mapping still needs to be
configured.
There is a list of phys_endpts for each localnet, one per chassis?
This replaces the bridge mapping configured on each hypervisor?
>> There are multiple phys_endpts, one per chassis
>> chassis and chassis_port are set per chassis
>> Each localnet port on a chassis is bound to a phys_endpt on that chassis
2. What is the relationship between the "chassis" column in port bindings, and
the "chassis" column in physical endpoints?
>> They are identical which I described in the original proposal e-mail as
>> somewhat redundant
>> The only reason to leave the chassis field in the port_binding record is for
>> non-localnet/non-gateway support to be unaffected
3. For L2 gateway, I think I am beginning to understand how this would work.
The L2 gateway still has to populate MACs up in southbound DB.
For L3 gateway, without a detailed proposal, I don't know how this fits
yet.
Are you adding a new port type for L3 external gateway ports?
>> Since the behavior of these ports will be different (for example for L3/L2
>> binding process details) it
>> will likely be necessary; L3 ports are logical ports
Are those ports bound to a chassis rather than run locally on each
ovn-controller?
>> These ports are bound to a gateway chassis
Are the provider networks run on only one chassis rather than each
ovn-controller?
>> a provider network runs on one gateway chassis or gateway chassis pair in
>> the case of redundant
>> from each HV, there should be/could be a tunnel to each gateway transport
>> node in the pair; possibly active/standby (A/S) default
To the extent that this proposal is meant to replace the “tag” column with
something more generic that can support different encapsulations, this is a
very good thing. As Kyle mentioned, we are interested in supporing VXLAN from
OpenStack/OVN to upstream physical routers.
Mickey
-----"dev" <dev-boun...@openvswitch.org> wrote: -----
To: Russell Bryant <russ...@ovn.org>, Darrell Lu <dlu...@gmail.com>,
"dev@openvswitch.org" <dev@openvswitch.org>
From: Darrell Ball
Sent by: "dev"
Date: 02/11/2016 01:51PM
Subject: Re: [ovs-dev] [OVS-dev]: OVN: RFC re: logical and physical endpoint
separation proposal
On 2/11/16, 12:20 PM, "Russell Bryant" <russ...@ovn.org> wrote:
>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" <russ...@ovn.org> wrote:
>>
>>> On 02/08/2016 12:05 PM, Darrell Ball wrote:
>>>> On 2/5/16, 12:23 PM, "Russell Bryant" <russ...@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=ls08
>>>> 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)?
There are two separate workflows for SW and HW gateways.
Hardware_vtep support remains for hardware gateways; the vtep schema
will certainly evolve as well to support the hardware gateways.
Since there is only minimal usage support of the VTEP schema today from a
SW gateway POV, in the form of the "vtep-emulator", not much is lost by
abandoning
the VTEP schema w.r.t. the new software gateway development.
There will be some loss of OVN gateway reference behavior for the hardware
vendors
since SW and HW gateways are working from different DB schemas, but since
hardware
vendor designs/implementations differ b/w themselves and from SW approaches,
there is limited value to be maintained by not splitting SW and HW support.
>
>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.
Ok, thanks
>
>--
>Russell Bryant
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
