Comment 4 for bug 1808062

1) In the example you show above, was L2pop enabled? Would l2pop be a solution for this?

I don't believe that l2pop would be a solution for this. The goal is to provide complete isolation for networks within an AZ, not only for resiliency but also for security. For that reason, the intent is to keep l2 from leaking from one AZ to another. If anything, I would think that l2pop for a given network would ideally be limited to a single AZ in this scenario.

2) Are you proposing to constrain networks to span only 1 AZ when the behavior proposed is enabled?

Yes, the goal is to constrain networks to a single AZ.

3) What would be the impact for the deployer in terms of networking nodes, etc?

The goal is to reduce the number of networking nodes. In the current architecture, if I want to create networks that only live within an AZ (for instance an edge site), I have to have dedicated networking nodes for that AZ. The goal would be to have centralized networking nodes that can support networks that exist only in one site.

For instance, suppose the following architecture:

1 central site with controllers and networking nodes
3 edge sites with compute and baremetal nodes (no networker nodes)

Each of the 3 edge sites will act as a Neutron AZ, with it's own DHCP and L3 agents. External connectivity will be provided by one or more provider networks in the edge sites. Internal connectivity within the edge site will be provided by VXLAN networks. Each VXLAN or provider network will only exist within an edge site AZ. Connectivity back to the central site is provided over L3 routes.

Another use case is within a single datacenter that has multiple security "zones". For security reasons, networks should only exist within a particular zone. This allows the creation of a production AZ, a staging AZ, and a DMZ AZ, with no shared networking between the 3 AZs. This can be achieved with separate networking nodes in each AZ, but it would be better if this could be done with only one set of networking nodes.