Open Stack

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