Wiki

• Date and Time: 6:00am PST / UTC 14:00, Thursday December 03, 2015
• Convener: Bin Hu (AT&T)
• Participants:
  • Bryan Sullivan (AT&T)
  • Dan Druta (AT&T)
  • Debra Scott (OPNFV)
  • Edgar St Pierre (EMC)
  • Ildiko Vancsa (Ericsson)
  • Julien Zhang (ZTE)
  • Larry Lamers (VMWare)
  • Malla Reddy Sama (DoCoMo)
  • Manuel Rebellon (Sandvine)
  • Mark Gray (Intel)
  • Mark Szczesniak (Casa)
  • Michael Bugenhagen (Century Link)
  • Stuart Mackie (Juniper)
  • Vikram Dham (Dell)

• Upstream Feature Development and Cross-Project Collaboration
  • Status update on active items
    • Security Group Update

Luke was not present. It might be because Luke already shared security group update at TSC meeting on Tuesday.

• Project Proposal Discussion
  • Active project proposals
    • OVN for NFV

Bryan (AT&T) initiated an email thread to discuss OVN as SDN solution. Vikram (Dell) collaborated with OVSNFV, VNFFG and ONOSFW projects in the past 2 weeks. Vikram shared the conclusion according to email discussion that Bryan initiated, and his collaborative discussion with OVSNFV, VNFFG and ONOSFW.

Regarding ovn4nfv and ovsnfv, Vikram indicated that ovsnfv focuses on enhancement of the OPNFV build by including a deployment option for the software-accelerated userspace Open vSwitch build. This work will significantly improve the performance of the NFVI for network I/O. Thus Vikram concluded that ovsnfv is orthogonal to ovn4nfv project's goal, which is to enable Open Virtual Networks (OVN) as another option for network control in OPNFV. ovn4nfv could leverage the work done by ovsnfv by using accelerated data path.

Mark (Intel) indicated that there is still a little bit overlap, because they will work on the same repo and code base. How do you plan to address this overlap? Vikram responded that there are code in ovn4nfv project for contribution to upstream. Bryan indicated that as long as there is fork, it should be fine. The goal is to have a single OPNFV.

Bin asked Mark if he can share his experience and methodology used in ovsnfv project to avoid fork, even no temporary repo and fork. Mark shared that they discussed several options during OPNFV summit. And the final conclusion is to work on upstream repo and code base, i.e. dependent on upstream community, even if there may be inevitable delays. This will reduce the complexity of managing forks. So there will be only one OPNFV build by referring the appropriate label in upstream, and recognizing that the desired feature may not be in that upstream label, and some delays are expected.

Bin suggested Vikram to use the same approach to avoid fork. Vikram agreed that it is the way to go.

Regarding ovn4nfv and VNFFG, Vikram shared that based on the community's discussion and VNFFG team's input, VNFFG focuses on providing SFC for OPNFV. This does not overlap with ovn4nfv, in fact ovn4nfv could help in providing a simpler SFC driver for VNFFG by using OVN. Currently VNFFG uses a local ovs agent for configuring OVS as an SFF. The functionality of local OVS agent can be ported to OVN. This work can be done by ovn4nfv and can be contributed back to upstream projects, which is already stated in ovn4nfv project goals.

Bryan asked if Vikram has considered the inter-DC connectivity across WAN. Vikram responded that it is not addressed yet, and it will be considered later.

Regarding ovn4nfv and ONOSFW, Vikram indicated that ONOSFW intends to use ONOS for network control, while ovn4nfv intends to implement network control using ovn + neutron. Southbound interface for ONOSFW can in fact be simplified by using OVN - no need for maintaining 2 drivers/connections, one for ovsdb and one for OpenFlow.

Bin asked if there are more comments on the ovn4nfv proposal before we conclude to recommend for TSC Creation Review. Bryan suggested that Vikram communicate his plan of avoiding fork of repo and code base in the mailing list so as to make sure everyone is on the same page. Vikram agreed.

Action Item for Vikram: communicate the plan and methodology of avoiding fork of repo and code base in the mailing list, given that ovn4nfv and ovsnfv will share the same repo and code base in upstream.

If there is no more comment on the plan and methodology by Monday morning (72 hours), community will recommend it for TSC creation review.

• AOB

Bryan asked the question about how to develop collaborative community to share the experience and expertise. For example, it is a challenge to have a new feature to support all 4 installers. Basically, Bryan's proposal include:
- Create a sub-community to share experience
- Community support to make it scalable to require all installers to support each new feature.

Action Item for Bryan: initiate the discussion and collaborative work with Genesis and all 4 installers.

Meeting adjourned.