Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-31 Thread Brian Haley
On 03/28/2016 07:17 PM, Carl Baldwin wrote: On Fri, Mar 11, 2016 at 10:04 PM, Salvatore Orlando wrote: On 11 March 2016 at 23:15, Carl Baldwin wrote: I wonder if we could satisfy this requirement with tags - as it seems these subnets are anyway

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-30 Thread Neil Jerram
On 29/03/16 21:55, Carl Baldwin wrote: > > I thought of another type of grouping which could benefit pluggable > IPAM today. It occurred to me as I was refreshing my memory on how > pluggable IPAM works when there are multiple subnets on a network. > Currently, Neutron's backend pulls the subnets

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-30 Thread Neil Jerram
On 29/03/16 19:16, Carl Baldwin wrote: > I've been playing with this a bit on this patch set [1]. I haven't > gotten very far yet but it has me thinking. > > Calico has a similar use case in mind as I do. Essentially, we both > want to group subnets to allow for aggregation of routes. (a) In >

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-30 Thread Neil Jerram
On 11/03/16 23:20, Carl Baldwin wrote: > Hi, Hi Carl, and sorry for the lateness of this reply. > I have started to get into coding [1] for the Neutron routed networks > specification [2]. > > This spec proposes a new association between network segments and > subnets. This affects how IPAM

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-29 Thread Carl Baldwin
On Tue, Mar 29, 2016 at 12:12 PM, Carl Baldwin wrote: > I've been playing with this a bit on this patch set [1]. I haven't > gotten very far yet but it has me thinking. > > Calico has a similar use case in mind as I do. Essentially, we both > want to group subnets to allow

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-29 Thread Carl Baldwin
I've been playing with this a bit on this patch set [1]. I haven't gotten very far yet but it has me thinking. Calico has a similar use case in mind as I do. Essentially, we both want to group subnets to allow for aggregation of routes. (a) In routed networks, we want to group them by segment

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-28 Thread Carl Baldwin
On Mon, Mar 21, 2016 at 12:52 PM, John Belamaric wrote: > Sorry for the slow reply. And, sorry for mine. I was distracted with dotting I's and crossing T's on some other things. I'm now back to playing around with this. > I think that both of these can be solved with

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-28 Thread Carl Baldwin
On Fri, Mar 11, 2016 at 10:04 PM, Salvatore Orlando wrote: > On 11 March 2016 at 23:15, Carl Baldwin wrote: > I wonder if we could satisfy this requirement with tags - as it seems these > subnets are anyway operator-owned you should probably not worry

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-21 Thread John Belamaric
Hi Carl, Sorry for the slow reply. I think that both of these can be solved with the existing interface, by expanding the different types of "request" objects. Right now, we have very basic and limited requests: SpecificSubnet, AnySubnet. There is no reason we can't create a subnet request

Re: [openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-11 Thread Salvatore Orlando
Some thoughts inline. Salvatore On 11 March 2016 at 23:15, Carl Baldwin wrote: > Hi, > > I have started to get into coding [1] for the Neutron routed networks > specification [2]. > > This spec proposes a new association between network segments and > subnets. This affects

[openstack-dev] [Neutron] Segments, subnet types, and IPAM

2016-03-11 Thread Carl Baldwin
Hi, I have started to get into coding [1] for the Neutron routed networks specification [2]. This spec proposes a new association between network segments and subnets. This affects how IPAM needs to work because until we know where the port is going to land, we cannot allocate an IP address for