Open Stack

On Jul 23, 2015 6:04 PM, "Kevin Benton" <blak111 at gmail.com> wrote:
>
> > IOW, I don't think what I
> proposed in adding L3 stuff to the network that wasn't already here.
>
> The point I'm trying to make is that there isn't any L3 stuff on the
network itself. There are L3 things that depend on the network because an
L2 network carries them. But the routed network proposes something that
depends on a network that doesn't actually exist as an L2 network and it
doesn't depend on the network for L2 transit. The network makes no sense
other than as a grouping mechanism.

There is no L3 stuff explicitly on the network but I'm not saying that
there is.  There doesn't have to be to support my argument.   Also, in my
proposal, it is more the router that is the grouping mechanism.

I acknowledge that the proposal ignores the L2 parts of the network.  That
isn't ideal.  But, I stand by the point that I'm attempting to make:  that
the network object is currently the closest thing we have to representing
the L3 part of the network.  It may not have been the original intention
but it is the reality.  My proposal isn't creating this situation, it is
merely shedding light on it.

> Even in the floating IP case, you allocate them from a network because
the network actually carries them. If you attach a VM to that network it
can arp for them and all because it is an L2 network.

We don't associate floating ips with a network because we want to arp for
them.  You're taking a consequence of the current model and its constraints
and presenting that as the motivation for the model.  We do so because
there is no better L3 object to associate it to.  The ability to arp for
them on an L2 network is inconsequential in a lot of applications.  We have
it only because that is the only way we support an external network.

A better L3 object might be nice.  Floating ips would come from the L3
network.  If there is an L2 network underneath, we could do the arp thing
if you care about that.  The model might be better that way.  However,
adding it to the model will require heavy lifting with big api impact and
significant database migration.  We have to look at the relationships of
all the basic objects:  ports, networks, subnets, and floating ips.  Do we
need an L3 port, for example?  If we insist on a new object for the L3 part
of a network then I'd say we had better have an L3 only port to connect to
it.  This stuff is hard.  While it would be nice, does it have to block any
progress on L3 network?  I'm sure many purists will say yes but I'm not
convinced yet.

The subnet is not the L3 object that we're looking for.  You may wish it
were but that does not make it so.  A subnet must have one and only one
cidr.  A cidr does not an L3 network make.  The subnet only makes sense in
the context of the network object to which it is associated.  That is not
because of any of the L2 attributes of the network.  Ignoring the forced
dependence on L2, the subnets still don't stand alone to describe just the
L3 part, they must be linked to a network to make any sense.  This is why I
continue to argue that the network is effectively our L2 and L3 lumped
together.

Imagine there were some new L3 network object in between the L2 and the
cidrs.  It could associate with the L2 object only if needed.  But, as I
say, inserting this new object has a big cost.  I'm not against doing this
modeling work if there is demand for it.  It might be fun.  But, I know it
will be a thankless job that will take an entire cycle at least and will
require changes to the api, client, horizon, etc.

Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150727/4a40f61d/attachment.html>