Open Stack

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
> 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.

Correct, and thanks for thinking about this case.

> (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).

When you say "a group id(s) can be passed", are you thinking of the API 
into Neutron (e.g. from Nova), or of the API between the Neutron core 
and a pluggable IPAM driver?  (Or some other API?)

My guess is you mean the API between Neutron core and a pluggable IPAM 
driver.  For that case, I think your suggestion would make sense if 
information about all available subnets was passed upfront to the driver 
- i.e. whenever the network/subnet data model changes - but I am not 
sure if that is what happens.  Rather, I think it might be the case that 
the available subnets/CIDRs are passed to the driver for each IP 
allocation that is wanted.

If that last sentence is correct, then the Neutron core could do the 
filtering-by-group-id itself, and simply pass a filtered set of 
subnets/CIDRs to the driver, and I think that that would be simpler.

> 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?

FWIW, I don't think so.  But I'd like to be a lot surer about the shape 
of the existing pluggable IPAM interface.

Regards,
	Neil