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