To be archived

Overview

The vFirewall is the easiest amongst all the use cases and is used heavily for automated regression by the Integration team and by ONAP users who test and try out the platform. Currently, the use case does not fully support integration of newer ONAP features and components. The goal is to bring it up to standard with other use cases within the scope of closeloop domain.

Problem Statement

This is a parent page to track all the items where we would use the vFW usecase to demonstrate new features and interactions in the closeloop domain.

Current controlloop workflow for vFW usecase

CDS actor support in Policy

Upgrading vFWCL Integration Test Case to Include DCAE-DS and CLAMP in El Alto/Frankfurt

Stretch and future items

Business Requirement

Use the vFW usecase to demonstrate new ONAP features and component interoperability within the scope of controlloop.

Participating Companies

AT&T, Bell, Samsung

Goals

  1. CDS actor support in Policy: To bring in integration of CDS into policy as another actor and demonstrate this integration using the vFirewall end-to-end closeloop usecase (design-time + runtime: instantiation and closeloop)
  2. ....


Contributions

Impacts

Impacts are tracked under each of the subpages

Open Questions


  • No labels

1 Comment

  1. Lukasz Rajewski

    Pamela Dragosh, Marco Platania, Ajay Mahimkar Hi, I would be very glad to share with you my opinions on vFW use case and where it should go. We have been using vFW for tests of DistributeTraffic LCM API in APPC and modified vFW template has been created which solves some problems (https://github.com/onap/demo/tree/master/heat/vFWDT).Along with modified heat we also were creating service in different way - having 1 instance of vPKG and 2 instances of vFW and vSINK. In order to distribute traffic from on vFW to the other one vPKG is reconfigured.

    It could very interesting to solve all this problems together what would help to leverage this use case in further work on Distribute Traffic mechanism. First issue is related with a static way how IP addresses are being assigned - NetBOX can solve it I suppose. VNF Preloading is also tedious but CDS should help in this. For further work on DistributeTraffic LCM API we would like also to modify use case a bit more to have following service chain: vPKG → vLB → vFW → vGW → vSINK. vLB would allow to test better traffic distribution mechanism - by possibility to distribute traffic i.e. with 50/50% pattern - now only 0/100% or 100/0% pattern is possible with 2 vFW instances. The other issue is with vSINK - without vGW it is necessary to reconfigure vSINK for different vFW (which acts a role of vGW in fact) or it is necessary to reconfigure destination of traffic in vPKG. Better would be to add vGW what would allow to keep configuration of vSINK and traffic destination on vPKG unchanged and only vLB would have to be reconfigured in order to perform traffic distribution.

    Interesting would be to make vFW ScaleOut and ScaleIn use case ready - in order to create second instance of vFW on-the-fly. It would help to leverage this use for design of full change workflow in Change Management Extensions project. Again very interesting would be to add here vLB and vGW because it would allow to scale vFW almost in zero downtime mode.