Open Stack

On Thu, Sep 17, 2015 at 10:26 AM, Kevin Benton <blak111 at 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