Open Stack

On Tue, Mar 29, 2016 at 1:38 PM, Miguel Lavalle <miguel at mlavalle.com> wrote:
> I am writing a patchset to build a mapping between hosts and network
> segments. The goal of this mapping is to be able to say whether a host has
> access to a given network segment. I am building this mapping assuming that
> if a host A has a bridges mapping containing 'physnet 1' and a segment has
> 'physnet 1' in its 'physical_network' attribute, then the host has access to
> that segment.

Miguel, thanks for starting this.  I don't have the answer but here
are some thoughts.

First, a segment in the model is defined by the combination of network
type, physical network, and segmentation id [1].  In theory, the same
physical network name could be used with different network types and
segmentation ids.  For example, it might be natural to express
different VLANS on the same physical switch using the same physical
network name.

But, the method you linked to [2] does seem to make the same
assumption.  So, in practice it seems to be a valid assumption.  A
patch that recently merged [3] to make DHCP physnet aware also seems
consistent with the assumption.

> 1) Is this assumption correct? Looking at method check_segment_for_agent in
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/ml2/drivers/mech_agent.py#n180

Careful, this reference can change as master updates this file.  :)

> seems to me to suggest that my assumption is correct?
>
> 2) Furthermore, when a segment is mapped to a physical network, is there a
> one to one relationship between segments and physical nets?

The routed networks use case can go either way.  We can easily live
with using a different physical network for each segment.  It might be
a bit awkward in a some situations (e.g. same router/switch serving
multiple segments) but I imagine that it might be more important to be
able to reuse VLAN ids across segments because VLAN ids can be scarce.
That would require that the physical network be unique for each.

I think this discussion is about what is the right thing to do
regardless of what the routed networks use case might or might not
need.  What are other use cases that might be relevant to this
discussion?

Carl

[1] https://github.com/openstack/neutron/blob/4a6d05e410/neutron/extensions/providernet.py#L33
[2] https://github.com/openstack/neutron/blob/4a6d05e410/neutron/plugins/ml2/drivers/mech_agent.py#L180
[3] https://review.openstack.org/#/c/205631/