Open Stack

On Thu, Jul 23, 2015 at 1:45 PM, Kevin Benton <blak111 at gmail.com> wrote:
>>We ran in to this long ago.
>
> What are some other examples? We've be good about keeping the network L2
> only. Segments, VLAN transparency, and other properties of the network are
> all L2.

Another thing is that we create floating IPs from external networks,
not subnets.  The individual subnets on an external network aren't
important to the end user, it is the collections of subnets that makes
up the address pool for the external network.  The end user doesn't
care about anything about the L2 part of an external network.  They
want to connect externally with L3 through their routers.  But, we
don't have anything to represent that external L3 network so we have
them select a floating_network_id.  If we had something to represent
the L3 part of a network wouldn't it make more sense for the user to
select that?  We don't, so they can't.

A neutron subnet is locked to a cidr which is too limiting to be useful.

I want floating IPs to work on these routed networks.  The current
model dictates that it be a neutron network for this to happen.  I'm
not opposed to suggestions to improve the model, I actually started
sketching some out at the mid-cycle.  But, it is invasive and will be
extremely difficult and painful.  Possibly prohibitively so.  I guess
I thought there might be a way without the pain.

> The example you gave about needing the network to see the grouping of
> subnets isn't the network leaking into L3, it's subnets requiring an L2
> container. Networks don't depend on subnets, subnets depend on networks. I
> would rather look at making that dependency nullable and achieving your
> grouping another way (e.g. subnetpool).

Yes, subnets require a network but I still think it is more than that.

> The issue I have with the routed network it's using a network but it ignores
> any of the properties of the network model because they are L2. So now we
> have an API that stops making sense for one of the object types (e.g. what
> would vlan transparency or mtu do on a routed network?), which is something
> I don't want to see.

I don't disagree that we could have a better model.  It is not a good
thing to ignore those attributes of the network.  My position is just
that the L3 parts are already tangled up in there somehow.  We either
need to improve the model or accept it.  IOW, I don't think what I
proposed in adding L3 stuff to the network that wasn't already here.
It is just proposing to ignore the L2 stuff for a new kind of network.

Carl