Open Stack

Thanks so much for your continuing answers; they are really helping me.

I see your points now about the special casing, and about the semantic
expectations and internal wiring of a Neutron network being just the
same for an external network as for non-external.  Hence, the model for
an L3-only external network should be the same as it would be for an
L3-only tenant network, except for the router:external flag (and might
be along the lines that you've suggested, of a subnet with a null network).

It still seems that 'router:external true' might be a good match for
some of the other 'routed' semantics in [1], though, so I'd like to
drill down more on exactly what 'router:external true' means.

A summary of the semantics at [1] is:
(a) L3-only connectivity between instances attached to the network.
(b) Data can be routed between between this network and the outside, and
between multiple networks of this type, without needing Neutron routers
(c) Floating IPs are not supported for instances on this network. 
Instead, wherever an instance needs to be routable from, attach it to a
network with a subnet of IP addresses that are routable from that place.

[1] https://review.openstack.org/#/c/198439/

According to [2], router:external "Indicates whether this network is
externally accessible."  Which I think is an exact match for (b) - would
you agree?  (Note: it can't mean that every instance on that network
actually _is_ contactable from outside, because that depends on IP
addressing, and router:external is a network property, not subnet.  But
it can mean that every instance is _potentially_ contactable, without
the mediation of a Neutron router.)

[2] http://developer.openstack.org/api-ref-networking-v2-ext.html

Also I believe that (c) is already true for Neutron external networks -
i.e. it doesn't make sense to assign a floating IP to an instance that
is directly on an external network.  Is that correct?

In summary, for the semantics that I'm wanting to model, it sounds like
router:external true already gives me 2 of the 3 main pieces.  There's
still serious work needed for (a), but that's really nice news, if I'm
seeing things correctly (since discovering that instances can be
attached to an external network).

Regards,
    Neil




On 17/09/15 17:29, Kevin Benton wrote:
>
> Yes, the L2 semantics apply to the external network as well (at least
> with ML2).
>
> One example of the special casing is the external_network_bridge
> option in the L3 agent. That would cause the agent to plug directly
> into a bridge so none of the normal L2 agent wiring would occur. With
> the L2 bridge_mappings option there is no reason for this to exist
> anymore because it ignoring network attributes makes debugging a
> nightmare.
>
> >Yes, that makes sense.  Clearly the core semantic there is IP.  I can
> imagine reasonable variation on less core details, e.g. L2 broadcast vs.
> NBMA.  Perhaps it would be acceptable, if use cases need it, for such
> details to be described by flags on the external network object.
>
> An external network object is just a regular network object with a
> router:external flag set to true. Any changes to it would have to make
> sense in the context of all networks. That's why I want to make sure
> that whatever we come up with makes sense in all contexts and isn't
> just a bolt on corner case.
>
> On Sep 17, 2015 8:21 AM, "Neil Jerram" <Neil.Jerram at metaswitch.com
> <mailto:Neil.Jerram at metaswitch.com>> wrote:
>
>     Thanks, Kevin.  Some further queries, then:
>
>     On 17/09/15 15:49, Kevin Benton wrote:
>     >
>     > It's not true for all plugins, but an external network should
>     provide
>     > the same semantics of a normal network.
>     >
>     Yes, that makes sense.  Clearly the core semantic there is IP.  I can
>     imagine reasonable variation on less core details, e.g. L2
>     broadcast vs.
>     NBMA.  Perhaps it would be acceptable, if use cases need it, for such
>     details to be described by flags on the external network object.
>
>     I'm also wondering about what you wrote in the recent thread with Carl
>     about representing a network connected by routers.  I think you were
>     arguing that a L3-only network should not be represented by a kind of
>     Neutron network object, because a Neutron network has so many L2
>     properties/semantics that it just doesn't make sense, and better
>     to have
>     a different kind of object for L3-only.  Do those L2
>     properties/semantics apply to an external network too?
>
>     > The only difference is that it allows router gateway interfaces
>     to be
>     > attached to it.
>     >
>     Right.  From a networking-calico perspective, I think that means that
>     the implementation should (eventually) support that, and hence allow
>     interconnection between the external network and private Neutron
>     networks.
>
>     > We want to get rid of as much special casing as possible for the
>     > external network.
>     >
>     I don't understand here.  What 'special casing' do you mean?
>
>     Regards,
>         Neil
>
>     > On Sep 17, 2015 7:02 AM, "Neil Jerram"
>     <Neil.Jerram at metaswitch.com <mailto:Neil.Jerram at metaswitch.com>
>     > <mailto:Neil.Jerram at metaswitch.com
>     <mailto:Neil.Jerram at metaswitch.com>>> wrote:
>     >
>     >     Thanks to the interesting 'default network model' thread, I
>     now know
>     >     that Neutron allows booting a VM on an external network.
>     :-)  I didn't
>     >     realize that before!
>     >
>     >     So, I'm now wondering what connectivity semantics are
>     expected (or
>     >     even
>     >     specified!) for such VMs, and whether they're the same as -
>     or very
>     >     similar to - the 'routed' networking semantics I've
>     described at [1].
>     >
>     >     [1]
>     >   
>      https://review.openstack.org/#/c/198439/5/doc/source/devref/routed_networks.rst
>     >
>     >     Specifically I wonder if VM's attached to an external network
>     >     expect any
>     >     particular L2 characteristics, such as being able to L2
>     broadcast to
>     >     each other?
>     >
>     >     By way of context - i.e. why am I asking this?...   The
>     >     networking-calico project [2] provides an implementation of the
>     >     'routed'
>     >     semantics at [1], but only if one suspends belief in some of the
>     >     Neutron
>     >     semantics associated with non-external networks, such as
>     needing a
>     >     virtual router to provide connectivity to the outside
>     world.  (Because
>     >     networking-calico provides that external connectivity
>     without any
>     >     virtual router.)  Therefore we believe that we need to
>     propose some
>     >     enhancement of the Neutron API and data model, so that
>     Neutron can
>     >     describe 'routed' semantics as well as all the traditional
>     ones.  But,
>     >     if what we are doing is semantically equivalent to
>     'attaching to an
>     >     external network', perhaps no such enhancement is needed...
>     >
>     >     [2]
>     https://git.openstack.org/cgit/openstack/networking-calico
>     <https://git.openstack.org/cgit/openstack/networking-calico>
>     >     <https://git.openstack.org/cgit/openstack/networking-calico>
>     >
>     >     Many thanks for any input!
>     >
>     >         Neil
>     >
>     >
>     >   
>      __________________________________________________________________________
>     >     OpenStack Development Mailing List (not for usage questions)
>     >     Unsubscribe:
>     >   
>      OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     >   
>      <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     >   
>      http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     >
>
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>