Jonne asked why IPv6 Prefix Delegation only supports /64 prefix. Sridhar and Bin indicated that it is a limitation in current implementation for Kilo. Sub-delegation capability such as /48, /54 etc. should be supported beyond Kilo, and hopefully in Liberty.
Group agreed to look into IPv6 First-Hop Security, and use cases of Static IPv6 and Sub-delegation. Based on further investigation, we will decide possible actions, for example, Blueprints to drive IPv6 First-Hop Security, Static IPv6 and Sub-delegation capability.
Mark revised the PoC design of using VM as an IPv6 SLAAC Router for VMs.
Sridhar suggested to rename the "Provider Network" in OVS to "Tenant Network", and remove the "Provider Network" within the physical switch.
Mark asked if Tenant Router created in Network Node is needed or not in case of IPv6, because it is needed for IPv4 but not sure for IPv6.
Sridhar indicated that Tenant Router and Bridge are needed for each Tenant subnet. A dual-stack support is an easier way compared to IPv6-only design, because IPv4 is needed frequently from time to time, such as metadata.
Iben suggested a more generic diagram so that the design can be applied to other types of networks such as VXLAN, GRE, etc. through ML2 plugin. For example OVS Tunnling.
Bin suggested that we may have 2 diagrams. One is an simple diagram that maps to current OVS network setup, and the other one is a more generic one that can be easily scalable to other networks.
Mark will revise the PoC 1 design so that:
It is targeted for dual-stack
Revise the terminology of "Provider Network" to "Tenant Network"
One diagram shows the simple setup that maps to current network setup
The other diagram shows the generic scalability to other networks (VXLAN, GRE etc) through ML2 plugin
Sridhar also indicated an issue that current anti-spoofing rule implemented in ML2 may prohibit us from using VM as an IPv6 router
A Blueprint Port Security Extension for ML2 Plugin and IptablesFirewallDriver is approved and will make it possible for VM to forward traffic flow as needed (meaning acting as an IPv6 router). But it will be in Kilo release. Backporting it to Juno will be difficult.
Iben shared information of how to allow all traffic between VMs without disabling security group, for example empty rule table in default group. Iben also shared Using RDO Packstack to Build Neutron
Mark indicated that ClearPath might have some prior experience too.
Three more action items:
Mark will investigate how it was done in ClearPath before
Sridhar will check if anti-spoofing rule has higher priority than other rules in security group, and what are the possible paths to work around it.
Iben will do more experiment of changing configuration in order to allow ingress/egree traffic in VMs.
Next Steps / New Actions
All look into IPv6 First-Hop Security, and use cases of Static IPv6 and Sub-delegation
Group will make an informed decision of further steps of Blueprints if needed
Mark will further sketch out the design (see notes above) - dual stack, terminology change and 2 diagrams
Mark, Sridhar and Iben will investigate how to override anti-spoofing rule in Juno in order to make PoC 1 design feasible in Juno. Three paths will be investigated in parallel so that we can have a solid solution next week.
