<p dir="ltr">Great. I'll try to review as soon as possible since these will be big changes. </p>
<div class="gmail_quote">On Sep 17, 2015 12:44 PM, "Carl Baldwin" <<a href="mailto:carl@ecbaldwin.net">carl@ecbaldwin.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton <<a href="mailto:blak111@gmail.com">blak111@gmail.com</a>> wrote:<br>
> Yes, the L2 semantics apply to the external network as well (at least with<br>
> ML2).<br>
<br>
This is true and should remain so.  I think we've come to the<br>
agreement that a neutron Network, external, shared, or not, should be<br>
an L2 broadcast domain and have these semantics uniformly.<br>
<br>
> One example of the special casing is the external_network_bridge option in<br>
> the L3 agent. That would cause the agent to plug directly into a bridge so<br>
> none of the normal L2 agent wiring would occur. With the L2 bridge_mappings<br>
> option there is no reason for this to exist anymore because it ignoring<br>
> network attributes makes debugging a nightmare.<br>
<br>
+1<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>
> An external network object is just a regular network object with a<br>
> router:external flag set to true. Any changes to it would have to make sense<br>
> in the context of all networks. That's why I want to make sure that whatever<br>
> we come up with makes sense in all contexts and isn't just a bolt on corner<br>
> case.<br>
<br>
I have been working on a proposal around adding better L3 modeling to<br>
Neutron.  I will have something up by the end of this week.  As a<br>
preview, my current thinking is that we should add a new object to<br>
represent an L3 domain.  I will propose that floating ips move to<br>
reference this object instead of a network.  I'm also thinking that a<br>
router's external gateway will reference an instance of this new<br>
object instead of a Network object.  To cover current use cases, a<br>
Network would own one of these new instances to define the subnets<br>
that live on the network.  I think we'll also have the flexibility to<br>
create an L3 only domain or one that spans a group of L2 networks like<br>
what is being requested by operators [1].<br>
<br>
We can also discuss in the context of this proposal how a Port may be<br>
able to associate with L3-only.  As you know, ports need to provide<br>
certain L2 services to VMs in order for them to operate.  But, does<br>
this mean they need to associate to a neutron Network directly?  I<br>
don't know yet but I tend to think that the model could support this<br>
as long as VM ports have a driver like Calico behind them to support<br>
the VMs' dependence on DHCP and ARP.<br>
<br>
This is all going to take a fair amount of work.  I'm hoping a good<br>
chunk of it will fit in the Mitaka cycle.<br>
<br>
Carl<br>
<br>
[1] <a href="https://bugs.launchpad.net/neutron/+bug/1458890" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1458890</a><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>