Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
==== Minutes of IPv6 Project Meeting on March 06, 2015 ====

  * ''Date and Time'': UTC 17:00, Friday March 06, 2015
  * ''Convenor'': Bin Hu (AT&T)
  * ''Participants'':
    * Bryan Sullivan (AT&T)
    * David Karr (AT&T)
    * Fahd Abidi (EZchip)
    * Iben Rodriguez (Spirent)
    * Jonne Soininen (Nokia)
    * Mark Medina (ClearPath)
    * Sridhar Gaddam (RedHat)
    * Srinivas Vegesna (Criterion Networks)

  * Admin Update

Bin introduced the wiki page change of IPv6 meetings. Jira tools were created, and Gerrit repository was there too.

  * Status Update.
    * Sridhar gave an update of Use Case and Gap Analysis:
      * Static IPv6 address capability was disabled by patch https://review.openstack.org/#/c/129144/.
        * Jonne indicated that static IPv6 address will still be useful, for example, from DNS.
      * Full support for IPv6 tcp/udp/icmp IPv6 security groups: Sridhar talked to the author of Blueprint [[https://blueprints.launchpad.net/neutron/+spec/security-group-ipv6-ra-guard|Security group rule for IPv6 RA guard and IPv6 Snooping]]. The author is looking at the feature [[http://www.cisco.com/web/about/security/intelligence/ipv6_first_hop.html| IPv6 First-Hop Security]].
    * Jonne asked why [[https://blueprints.launchpad.net/neutron/+spec/ipv6-prefix-delegation| 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.
      * Mark shared   * [[http://klub.com.pl/dhcpv6/| Dibbler - A Portable DHCPv6]]
    * 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 [[http://docs.openstack.org/admin-guide-cloud/content/figures/14/a/a/common/figures/OVStunneling.png| 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 [[http://specs.openstack.org/openstack/neutron-specs/specs/kilo/ml2-ovs-portsecurity.html| 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 [[http://www.ibenit.com/post/90765117908/using-red-hat-rdo-packstack-to-build-openstack| 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.

Meeting adjourned.
Wiki

User Tools

Site Tools

Page Tools
