On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton <blak...@gmail.com> wrote: > Yes, the L2 semantics apply to the external network as well (at least with > ML2).
This is true and should remain so. I think we've come to the agreement that a neutron Network, external, shared, or not, should be an L2 broadcast domain and have these semantics uniformly. > 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. +1 >>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. I have been working on a proposal around adding better L3 modeling to Neutron. I will have something up by the end of this week. As a preview, my current thinking is that we should add a new object to represent an L3 domain. I will propose that floating ips move to reference this object instead of a network. I'm also thinking that a router's external gateway will reference an instance of this new object instead of a Network object. To cover current use cases, a Network would own one of these new instances to define the subnets that live on the network. I think we'll also have the flexibility to create an L3 only domain or one that spans a group of L2 networks like what is being requested by operators [1]. We can also discuss in the context of this proposal how a Port may be able to associate with L3-only. As you know, ports need to provide certain L2 services to VMs in order for them to operate. But, does this mean they need to associate to a neutron Network directly? I don't know yet but I tend to think that the model could support this as long as VM ports have a driver like Calico behind them to support the VMs' dependence on DHCP and ARP. This is all going to take a fair amount of work. I'm hoping a good chunk of it will fit in the Mitaka cycle. Carl [1] https://bugs.launchpad.net/neutron/+bug/1458890 __________________________________________________________________________ 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