Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-26 Thread Kevin Benton
That's just what I mean about horizontal, which is limited for some features. For example, ports belonging to BSN driver and OVS driver can't communicate with each other in the same tunnel network, neither does security group across both sides. There is no tunnel network in this case, just VLAN

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread Kevin Benton
The fact that a system doesn't use a neutron agent is not a good justification for monolithic vs driver. The VLAN drivers co-exist with OVS just fine when using VLAN encapsulation even though some are agent-less. There is a missing way to coordinate connectivity with tunnel networks across

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread Kevin Benton
Yeah, it seems ML2 at the least should save you a lot of boilerplate. On Feb 25, 2015 2:32 AM, Russell Bryant rbry...@redhat.com wrote: On 02/24/2015 05:38 PM, Kevin Benton wrote: OVN implementing it's own control plane isn't a good reason to make it a monolithic plugin. Many of the ML2

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread Kevin Benton
You can horizontally split as well (if I understand what axis definitions you are using). The Big Switch driver for example will bind ports that belong to hypervisors running IVS while leaving the OVS driver to bind ports attached to hypervisors running OVS. I don't fully understand your comments

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread Kevin Benton
In the cases I'm referring to, OVS handles the security groups and vswitch. The other drivers handle fabric configuration for VLAN tagging to the host and whatever other plumbing they want to do. On Feb 25, 2015 5:30 PM, loy wolfe loywo...@gmail.com wrote: On Thu, Feb 26, 2015 at 3:51 AM,

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread loy wolfe
Oh, what you mean is vertical splitting, while I'm talking about horizontal splitting. I'm a little confused about why Neutron is designed so differently with Nova and Cinder. In fact MD could be very simple, delegating nearly all things out to agent. Remember Cinder volume manager? The real

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread loy wolfe
On Thu, Feb 26, 2015 at 3:51 AM, Kevin Benton blak...@gmail.com wrote: The fact that a system doesn't use a neutron agent is not a good justification for monolithic vs driver. The VLAN drivers co-exist with OVS just fine when using VLAN encapsulation even though some are agent-less. so how

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread loy wolfe
On Thu, Feb 26, 2015 at 10:50 AM, Kevin Benton blak...@gmail.com wrote: You can horizontally split as well (if I understand what axis definitions you are using). The Big Switch driver for example will bind ports that belong to hypervisors running IVS while leaving the OVS driver to bind ports

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread Russell Bryant
On 02/24/2015 05:38 PM, Kevin Benton wrote: OVN implementing it's own control plane isn't a good reason to make it a monolithic plugin. Many of the ML2 drivers are for technologies with their own control plane. Going with the monolithic plugin only makes sense if you are certain that you

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread Fawad Khaliq
On Wed, Feb 25, 2015 at 5:34 AM, Sukhdev Kapur sukhdevka...@gmail.com wrote: Folks, A great discussion. I am not expert at OVN, hence, want to ask a question. The answer may make a case that it should probably be a ML2 driver as oppose to monolithic plugin. Say a customer want to deploy

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-25 Thread loy wolfe
+1 to separate monolithic OVN plugin The ML2 has been designed for co-existing of multiple heterogeneous backends, it works well for all agent solutions: OVS, Linux Bridge, and even ofagent. However, when things come with all kinds of agentless solutions, especially all kinds of SDN controller

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-24 Thread Kyle Mestery
On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando sorla...@nicira.com wrote: On 24 February 2015 at 01:34, Kyle Mestery mest...@mestery.com wrote: Russel and I have already merged the initial ML2 skeleton driver [1]. The thinking is that we can always revert to a non-ML2 driver if needed.

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-24 Thread Kevin Benton
OVN implementing it's own control plane isn't a good reason to make it a monolithic plugin. Many of the ML2 drivers are for technologies with their own control plane. Going with the monolithic plugin only makes sense if you are certain that you never want interoperability with other technologies

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-24 Thread Salvatore Orlando
I think we're speculating a lot about what would be best for OVN whereas we should probably just expose pro and cons of ML2 drivers vs standalone plugin (as I said earlier on indeed it does not necessarily imply monolithic *) I reckon the job of the Neutron community is to provide a full picture

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-24 Thread Amit Kumar Saha (amisaha)
25, 2015 6:04 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN Folks, A great discussion. I am not expert at OVN, hence, want to ask a question. The answer may make a case that it should probably be a ML2

Re: [openstack-dev] [neutron] ML2 versus core plugin for OVN

2015-02-24 Thread Sukhdev Kapur
Folks, A great discussion. I am not expert at OVN, hence, want to ask a question. The answer may make a case that it should probably be a ML2 driver as oppose to monolithic plugin. Say a customer want to deploy an OVN based solution and use HW devices from one vendor for L2 and L3 (e.g. Arista