[openstack-dev] [Neutron][L3] Representing a networks connected by routers

Kevin Benton blak111 at gmail.com
Fri Jul 24 00:02:30 UTC 2015

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

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.
On Jul 23, 2015 5:09 PM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:

> 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
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150723/a19124d8/attachment.html>

More information about the OpenStack-dev mailing list