...
- Various types of container implementations
- Other light weight compute choices e.g. kotakata, virtlet, unikernels
- Performance, security, other aspects of container improvement
- Storage support in the cloud native environment
- Orchestration : Kubernetes (auto deployment, scaling, management etc.), Kubernetes + Openstack (including Kubernetes on Openstack, and other variations)
- Integration of these upstream components
- Goal is to move the integration process to XCI style continuous integration with both Openstack and Kubernetes
...
- 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, 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). 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.
...