<p dir="ltr">On Jul 23, 2015 6:04 PM, "Kevin Benton" <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> wrote:<br>
><br>
> > IOW, I don't think what I<br>
> proposed in adding L3 stuff to the network that wasn't already here.<br>
><br>
> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">> 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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.  </p>
<p dir="ltr">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.</p>
<p dir="ltr">Carl</p>