...
Consider to dedicate a POD in UNH LaaS to be OPNFV's long running testbed.
5) Support for "MiddleBox" Network Functions
While the adoption of technologies like the Micro-Services (number 3 above) are very well suited to services that operate at layer 7 (such as management and control functions), the interface to these service meshes does not provide access to the entire raw packet which is necessary for many data plane functions.
There needs to be support for a different framework to support L3/4 functions, such that packet headers can be inspected and appropriate action taken. Examples would be vCPE or vEPC.
In addition these network functions often need to be able to be connected in a logical sequence. In an OpenStack / VM based environment this would be called a Service Function Chain, but we won't use this term as it may implpy a certain implementation. ETSI uses the term VNF Forwarding Graph, and this kind of logical sequence of functions is required, regardless of how it is implemented.
Recommendation #5:
Review existing open source projects to achieve the needs of a middlebox network function. An example would be Ligato, which makes use of fd.io (see https://github.com/ligato).
6) Concrete use cases and sample applications
- Use case driven (user/customer driven) is an important way to make OPNFV more relevant to customer needs and be more "consumable".
- Work cross project to identify common priority use cases. Future deployment should be a focus for us as today's commercial deployment has yet to adopt cloud native in large scale.
- One of the outcome of these sample VNFs should be a best practice document helping the community/vendors/customers understand the challenges involved and best methodology of moving to cloud native.
- It will be greatly beneficial is projects within LFN, and other related upstream projects, can share work on use cases and examples. Specifically, we should join forces in creating cloud native use cases.
Recommendation #5#6:
Work across projects to create a set of common use cases that reflect shared market requirements.
67) Cross project collaborations
- ONAP also aims to move to cloud native. We need to position OPNFV in helping ONAP achieve their goals without unnecessary replication.
- Auto project is working on running ONAP on OPNFV VIM. It will be beneficial to run ONAP as a cloud native application on OPNFV's cloud native infrastructure.
- FD.IO has goals in high performance data path for cloud native VNFs. We should investigate best way to integrate that as one of the acceleration methods.
- The CD (continuous deployment) initiative is applicable for all projects within LFN, and related to upstream (CNCF, Openstack), and compliments to the XCI initiative, Lab-as-a-service/Pharos etc.
- Cloud native is a general theme that we should push together in LFN.
Recommendation #6#7:
OPNFV should take a lead to drive a LFN cloud native initiative.
...