Open Stack

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.

Given all this grouping, it seems like it might make sense to add some
sort of grouping feature to IPAM.  Here's how I'm thinking it will
work.

1.  When a subnet is allocated, a group id(s) can be passed with the
request.  IPAM will remember the group id with the subnet.
2.  When an IP address is needed, a group id(s) can be passed with the
request.  IPAM will try to allocate from a subnet with a matching
group id(s).
3.  If no IP address is available that exactly matches the group id(s)
then IPAM may fall back to another subnet.  This behavior needs to be
different for the various use cases mentioned which is where it gets
kind of complicated.
  (a) No fallback is allowed.  The IP allocation should fail.
  (b) We can fall back to any other subnet.  There might be some
reasons to prefer some over others but this could get complicated
fast.
  (c) We can fall back to any subnet with None as its group (legacy
subnets) but not to other groups (e.g. if I'm trying to allocate a
floating IP address, I don't want to fall back to a subnet meant for
DVR gateways because those aren't public IP addresses).

I put (s) after group id in many cases above because it appears that
we can have more than one kind of orthogonal grouping to consider at
the same time.

What do folks think?

Am I trying to generalize too much and making it complicated?

What are some alternatives?

Are there other compelling use cases that I haven't considered yet?

Carl

[1] https://review.openstack.org/#/c/288774

On Fri, Mar 11, 2016 at 4:15 PM, Carl Baldwin <carl at ecbaldwin.net> 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 how IPAM needs to work because until we know
> where the port is going to land, we cannot allocate an IP address for
> it.  Also, IPAM will need to somehow be aware of segments.  We have
> proposed a host / segment mapping which could be transformed to a host
> / subnet mapping for IPAM purposes.
>
> I wanted to get the opinion of folks like Salvatore, John Belamaric,
> and you (if you interested) on this.  How will this affect the
> interface to pluggable IPAM and how can pluggable implementations can
> accommodate this change.  Obviously, we wouldn't require
> implementations to support it but routed networks wouldn't be very
> useful without it.  So, those implementations would not be compatible
> when routed networks are deployed.
>
> Another related topic was brought up in the recent Neutron mid-cycle.
> We talked about adding a service type attribute to to subnets.  The
> reason for this change is to allow operators to create special subnets
> on a network to be used only by certain kinds of ports.  For example,
> DVR fip namespace gateway ports burn a public IP for no good reason.
> This new feature would allow operators to create a special subnet in
> the network with private addressing only to be used by these ports.
>
> Another example would give operators the ability to use private
> subnets for router external gateway ports if shared SNAT is not needed
> or doesn't need to use public IPs.
>
> These are two ways in which subnets are taking on extra
> characteristics which distinguish them from other subnets on the same
> network.  That is why I lumped them together in to one thread.
>
> Carl