...
Focus on two main configurations: Kubernetes baremetal and Kubernetes on top of Openstack.
Sync with the ongoing efforts of consolidation through XCI and converge on a common set.
2) Container networking
- There are many aspects of container networking, some involve VNF data path, but many don't. (Note: the phrase "data path" is ambiguous).
- For the normal case, we should stay fully faithful to Kubernetes and CNCF, and participate in the ongoing efforts there (upstream first). This should be our baseline in producing a consumable Kubernetes configuration (see Recommendation #1). container4nfv, e.g., supports CNI, multus, SRIOV etc.
- For the "bump-in-the-wire" case, a.k.a "middle box", various acceleration designs have been proposed/developed, OPNFV should work with related projects to test/validate their applicability with respect to solving user's demonstrated requirements. Some of these are based on ongoing data path work within OPNFV and projects within LFN (e.g. ligato/FD.IO in user space), and others in open source community (e.g. Linux BPF in kernel space). See a separate bullet below to distinguish this case. These acceleration methods are critical to many NFV use cases, but we should not mix importance with maturity, the promotion of these features should be gated with a neutral set of test cases. Doing so is not to demote its importance, but to give space and freedom in its development so those projects can move faster.
- We are not here to "choose", but provide a consistent validation process to test features, gauge maturity, and help down-stream to consume these features in an easier way. All solutions demonstrated benefits and maturity should be promoted to the same level.
...
Review existing open source projects to achieve the needs of a middlebox network function. An example, implemented in user space, would be Ligato, which makes use of fd.io (see https://github.com/ligato). Another example, implemented in kernel space, is BPF.
6) Concrete use cases and sample applications
...