Bug 1659651

Summary: [RFE] Neutron Availability Zone support so Geneve tunnels are limited to within AZ
Product: Red Hat OpenStack Reporter: Dan Sneddon <dsneddon>
Component: python-networking-ovnAssignee: Lucas Alvares Gomes <lmartins>
Status: NEW --- QA Contact: Eran Kuris <ekuris>
Severity: medium Docs Contact:
Priority: low    
Version: 17.0 (Wallaby)CC: apevec, bcafarel, bdobreli, cfontain, chrisw, dalvarez, dsneddon, ealcaniz, gurpsing, jamsmith, jlibosva, lhh, majopela, ralonsoh, spower, sputhenp, tfreger
Target Milestone: gaKeywords: FutureFeature, Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1702550 (view as bug list) Environment:
Last Closed: 2020-11-04 19:56:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1702550    

Description Dan Sneddon 2018-12-14 22:04:26 UTC
Description of problem:
Creating multiple Neutron availability zones allows the operator to schedule DHCP and L3 agents within a single AZ. Neutron OVN will still try to form a Geneve mesh between all nodes in all availability zones, which creates inter-AZ dependencies and may not work when strict firewalls are placed between AZs. This bug is a clone of BZ 1658390, but that RFE applies to ML2/OVS and this RFE applies to OVN.

Version-Release number of selected component (if applicable):
OSP15/Stein

Actual results:
The desired end-state configuration would have separate DHCP and L3 agents hosted in each AZ, along with tunnels formed only inside the AZ. This would allow, for instance, multiple edge sites within a single deployment that each performed local networking only. Any particular Neutron network would be limited to one AZ. A new flag would allow AZs to be truly autonomous and remove cross-AZ dependencies.

Expected results:
This behavior should be configurable, so that L2 may be limited to a particular AZ, and no tunnels are formed between different AZs. This will prevent Neutron from trying to form tunnels when the tunnel cannot function, and may enhance security when AZs are in different security zones.

Additional info:
Note that it appears that NSX-T has a concept called "Transport Zones" that enables the feature that is being requested here. Compute nodes within a given transport zone will only be able to communicate with compute nodes within that same transport zone. This prevents network traffic from being sent between zones. More information here:

https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.3/com.vmware.nsxt.install.doc/GUID-F47989B2-2B9D-4214-B3BA-5DDF66A1B0E6.html

NSX-T also supports Availability Zones, but it appears that those are separate from the Transport Zone functionality:

https://docs.vmware.com/en/VMware-Integrated-OpenStack/5.0/com.vmware.openstack.admin.doc/GUID-37F0E9DE-BD19-4AB0-964C-D1D12B06345C.html

It's possible that limiting tunneling traffic to a particular AZ may be outside the intended functions of Neutron AZs, but I think this is a valid use case.

Comment 1 Dan Sneddon 2019-02-04 22:47:07 UTC
*** Bug 1672431 has been marked as a duplicate of this bug. ***

Comment 2 Dan Sneddon 2019-02-04 22:54:47 UTC
Moving this to the OVN component. If it turns out that we can implement this at a higher level in Neutron, we can reassign to the Neutron component.

See more at the upstream bug: https://bugs.launchpad.net/neutron/+bug/1808594

Comment 14 stchen 2020-11-04 19:56:29 UTC
Closing EOL, OSP 16.0 has been retired as of Oct 27, 2020

Comment 15 Brian Haley 2020-11-09 22:38:58 UTC
Re-opening targeted at 16.1