Open Stack

On Jul 23, 2015 8:39 PM, "Paul Carver" <pcarver at paulcarver.us> wrote:
> I think Kevin is right here. Network is fundamentally a layer 2
construct, it represents direct reachability. A network could in principle
support non-IP traffic (though in practice that may or may not work
depending on underlying implementation.) Subnet is fundamentally a layer 3
construct it represents addressing for traffic that may need to flow
between different networks (quite literally, that's where the name
*inter*net protocol comes from.)

See my reply to Kevin.  I know we all wish there was a clean separation
where the network is the L2 and subnet is the L3 but it just isn't the
reality we have.  It is subtle but the subnet is not this L3 construct that
we all wish we had.

> Because there is often a 1:1 relationship between network and subnet it's
easy to blur the distinction, but I think it's worth keeping the concepts
clear. An address scope or supernet (in the specific meaning of a
summarized collection of subnets (e.g. a /23 made up of 8 /26s)) is a more
accurate conceptual representation of multiple L2 segments with routing
between them.

Not all segmented networks can be summarized with one cidr.  In fact, show
me one that can be that isn't totally contrived.  In today's world, L3
networks are addressed with fragmented, misaligned, collections of disjoint
cidrs.  It is the collection of them that means something.  Without the
network object, you can't have the collection in our model so without the
network, you don't have an L3 network.  The network object is the L2 lumped
with the L3.

To claim that we can just go clean from here forward ignores the reality,
it doesn't address it.

I don't think that subnet pools or address scopes get us what we want
either.  But, I'm giving this some more thought.  I keep going back to
"what *should* a floating ip be associated to?"  It shouldn't be the
network directly, but there is currently nothing better.

Carl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150727/c2d1a4b5/attachment.html>