Open Stack

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

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

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.
On Jul 23, 2015 10:35 AM, "Carl Baldwin" <carl at ecbaldwin.net> wrote:

> On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton <blak111 at gmail.com> wrote:
> > I proposed the port scheduling RFE to deal with the part about selecting
> a
> > network that is appropriate for the port based on provided hints and
> > host_id. [1]
>
> Thanks for the pointer.  I hadn't paid much attention to this RFE yet.
>
> >>the neutron network might have been conceived as being just "a broadcast
> >> domain" but, in practice, it is L2 and L3.
> >
> > I disagree with this and I think we need to be very clear on what our API
> > constructs mean. If we don't, we will have constant proposals to smear
> the
> > boundaries between things, which is sort of what we are running into
> > already.
>
> We ran in to this long ago.
>
> > Today I can create a standalone network and attach ports to it. That
> network
> > is just an L2 broadcast domain and has no IP addresses or any L3 info
> > associated with it, but the ports can communicate via L2. The network
> > doesn't know anything about the l3 addresses and just forwards the
> traffic
> > according to L2 semantics.
>
> Sure, a network *can* be just L2.  But, my point is that when you
> start adding L3 on top of that network by adding subnets, the subnets
> don't fully encapsulate the L3 part.  A subnet is just a cidr but
> that's not enough.  To illustrate, the IPv4 part of the L3 network can
> have several cidrs lumped together.  The full IPv4 story on that
> network includes the collection of all of the IPv4 subnets associated
> to the network.  That collection belongs to the network.  Without
> going to the network, there is no way to describe L3 addresses that is
> more than just a single cidr.
>
> > The neutron subnet provides L3 addressing info that can be associated
> with
> > an arbitrary neutron network. To route between subnets, we attach
> routers to
> > subnets. It doesn't matter if those subnets are on the same or different
> > networks, because it's L3 and it doesn't matter.
> >
> > It is conceivable that we could remove the requirement for a subnet to
> have
> > an underlying network in the fully-routed case. However, that would mean
> we
> > would need to remove the requirement for a port to have a network as well
> > (unless this is only used for floating IPs).
>
> If we remove the requirement then we have no way to group cidrs
> together.  A single cidr isn't sufficient to express the addressing
> needed for an L3 network.  My L3 network could be a bunch of disjoint
> or fragmented cidrs lumped together.  They should all be considered
> equivalent addresses, they just aren't lined up in a perfect little
> cidr.
>
> John Belamaric made a good point that the closest thing that we have
> to representing an L3 domain right now is a subnet pool.  I'm still
> thinking about how we might be able to use this concept to help out
> this situation.
>
> Carl
>
> > 1. https://bugs.launchpad.net/neutron/+bug/1469668
>
> __________________________________________________________________________
> 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/e54d85b4/attachment.html>