There is no guarantee that two separate external networks will have routing connectivity to each other. It seems like your (b) statement implies that. On Sep 19, 2015 3:12 PM, "Neil Jerram" <neil.jer...@metaswitch.com> wrote:
> On 17/09/15 19:38, Kevin Benton wrote: > > router:external only affects the behavior of Neutron routers. It > > allows them to attach to it with an external gateway interface which > > implies NAT and floating IPs. > > I presume you're talking about the reference implementation here. OK, > but my concern first is about what it _means_, in particular for > instances attached to such a network. Which your next paragraph addresses: > > > > > From an instance's perspective, an external network would be no > > different than any other provider network scenario that uses a > > non-Neutron router. Nothing different happens with the routing of > > traffic. > > Right, thanks. It seems to me that you're saying the same thing here as > my (b) below. In case not, please do say more precisely what isn't > correct about my (b) statement. > > > > > >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? > > > > Well not floating IPs from the same external network, but you could > > conceivably have layers where one external network has an internal > > Neutron router interface that leads to another external network via a > > Neutron router. > > Agreed. > > Many thanks for your input in this thread! > > Regards, > Neil > > > > > > > On Thu, Sep 17, 2015 at 10:17 AM, Neil Jerram > > <neil.jer...@metaswitch.com <mailto:neil.jer...@metaswitch.com>> wrote: > > > > 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/ > > <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.jer...@metaswitch.com <mailto:neil.jer...@metaswitch.com> > > > <mailto:neil.jer...@metaswitch.com > > <mailto:neil.jer...@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.jer...@metaswitch.com > > <mailto:neil.jer...@metaswitch.com> > > <mailto:neil.jer...@metaswitch.com > > <mailto:neil.jer...@metaswitch.com>> > > > > <mailto:neil.jer...@metaswitch.com > > <mailto:neil.jer...@metaswitch.com> > > > <mailto:neil.jer...@metaswitch.com > > <mailto:neil.jer...@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-requ...@lists.openstack.org?subject:unsubscribe > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > > > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > > > > > > > > < > http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > > > > < > http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > > < > http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > -- > > Kevin Benton > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev