Open Stack

On Tue, Mar 29, 2016 at 12:12 PM, Carl Baldwin <carl at ecbaldwin.net> 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
> routed networks, we want to group them by segment and the boundaries
> are hard meaning that if an IP is requested from a particular segment,
> IPAM should fail if it can't allocate it from the same.
>
> (b) For Calico, I believe that the goal is to group by host.  Their
> boundaries are soft meaning that it is okay to allocate any IP on the
> network but one that allows maximum route aggregation is strongly
> preferred.
>
> (c) Brian Haley will soon post a spec to address the need to group
> subnets by service type.  This is another sort of grouping but is
> orthogonal to the need to group for routing purposes.  Here, we're
> trying to group like ports together so that we can use different types
> of addresses.  This kind of grouping could coexist with route grouping
> since they are orthogonal.

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  and then tries to ask
the IPAM driver for an IP on each one in turn [1].  This is
inefficient and I think it is a natural opportunity to evolve the IPAM
interface to allow this to be handled within the driver itself.  The
driver could optimize it to avoid repeated round-trips to an external
server.

Anyway, it occurred to me that this is just like segment aware IPAM
except that the network is the group instead of the segment.  The IPAM
driver could consider it another orthogonal grouping of subnets (even
though it isn't really orthogonal to Neutron's point of view).  I
could provide an implementation that would provide a shim for existing
IPAM drivers to work without modification.  In fact, I could do that
for all the types of grouping I've mentioned.  Drivers could choose to
sub-class the behavior to optimize it if they have the capability.

Carl

[1] https://github.com/openstack/neutron/blob/4a6d05e410/neutron/db/ipam_pluggable_backend.py#L88