...
- Would the use case(s) require multi-site support?
- Would the use case(s) require multi-region/multi-domain/federation support?
- Would the use case(s) require Multi-national support?
- Do we need to consider enhanced networking features (e.g., underlays)?
- For the Enterprise vCPE use case, we already consider the enhanced networking features both underlays and overlays. For the overlay layer, we support three alternatives ways to set up connection between vCPE/CPE and the firewall on the edge of TIC-core, including VxLAN, IPSec and MPLS. For the underlay layer, we proposed two new components including PCE (Path Calculation Element) and NAI (Network Artificial Intelligence) which support new features of network management including traffic scheduling, QoS support and traffic prediction. After the discussion of harmonization and simplification, we will take the underlay function as stretch goal of this case.
- Can individual use cases be built from same components? (common APIs/models)
- For the Enterprise vCPE use case, we can reuse the adjusted components from the Residential vCPE use case including multi-vim component, some of the VNFs and some parts of the infrastructure. In the E-vCPE use case, we may adapt different VNFs and also introduce some PNFs, as for the vCPE, those two use cases have quite different featuresPNF.
- What are the challenges from the first set of use cases?
- What technical debt have you identified?
- Right now the SDN-C may not fully support the PNFs which may have different versions and adapt different models apart from YANG. So, we may have the needs to introduce 3rd-party controllers to configure the PNFs mentioned above.
- Clarify business drivers and capabilities of the use cases
- For the Enterprise vCPE use case, it is mainly used for the Enterprise Service Provider (SP) to deploy enterprise-based vCPE to provide the Enterprise2DC service to the tenants both efficiently and safely. Enterprise users could receive high-quality and cheap cloud service based on the operator’s BSS Portal and ONAP. And in here, ONAP is used to instantiate and operate the required vCPE in the access network as a cloud service.It not only provides the solution of ThinCPE and vCPE in the edge-DC but also CPE solution as an alternative choice for enterprise customer. The solution of vCPE in the edge-DC is an actual deployment scheme which can provide more value-added service in DC and make it easy for access control.
- What are the functional commonalities between the use cases? Are there generic elements where we should focus?
- For the Enterprise vCPE use case, it can reuse some VNFs from other use cases such as vDHCP, vFW, vAAA, which requires similar functional capability about VNF configuration and management. Besides, E-vCPE and SD-WAN provide the Site2Site service and introduce the CPE into the system, which require the PNF configuration from SDNC.
- Clarification of requirements. For instance, you call out PNFs. What level of PNF support do you need for R2? Also, what are the requirements driving the need for PCE and NAI components? Could those be satisfied by existing components? If not, please clarify why not so that we can discuss how those components fit with the existing components and the rest of the architecture.
- For the Enterprise vCPE, we take the advices from others, after the usecase meeting about harmonization and simplification proposal. So we will take the underlay network management including the PCE and NAI components as a stretch goal.
In this release, we will focus on the overlay connection establishment between site to site/DC/Internet including alternative ways and the management of VNFs. If we take traffic scheduling function as a stretch goal , the configuration of ThinCPE/CPE on the custom site are the remaining function which the ONAP need to support in this release.
- For the Enterprise vCPE, we take the advices from others, after the usecase meeting about harmonization and simplification proposal. So we will take the underlay network management including the PCE and NAI components as a stretch goal.
- Discuss key features for R2. From what we can tell, multitenancy/slicing, WAN/connection types, and PNF support seem to be required. Are there others?
...