" John Belamaric made a good point that the closest thing that we have to representing an L3 domain right now is a subnet pool."
This is actually a really good point. If you take the example of a L3 network that spans segments, you could put something like a /16 into a subnet pool. That /16 can be allocated in smaller, non-uniformly sized chunks across multiple network segments. As you allocate chunks of the /16 across network segments, you need only identify the subnets allocated from your subnet pool and their associated Neutron networks to be able to stitch those segments together to represent the whole L3 network. Conveniently, we currently enforce the restriction that subnets on any given segment must all be allocated from the same subnet pool which makes stitching segments together in this way feasible. This is an existing construct that seems to model the world the way you want. I think we should at least explore this angle, there are still potentially some gotchas with regard to the interface with Nova that I haven't though. -Ryan -----Original Message----- From: Carl Baldwin [mailto:[email protected]] Sent: Thursday, July 23, 2015 9:26 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][L3] Representing a networks connected by routers On Wed, Jul 22, 2015 at 3:00 PM, Kevin Benton <[email protected]> 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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
