Topics

#ctrl-loop #integration Improvements to vFWCL regarding control loops #integration #controlloop


t.puha@...
 

Hi,

 

Referring to our discussion on this Wednesday’s control loop subcommittee meeting, it felt that we have quite a different view on what is actually included in current vFWCL case. To get some clarity to that, I checked what our guys had actually done with Casablanca vFWCL. See https://gerrit.onap.org/r/gitweb?p=oom/offline-installer.git;a=blob;f=docs/vFWCL-notes.rst;h=690b6dc9ec3c19cc225f6f495c8711b098f91008;hb=refs/heads/casablanca for details and it seems to fit my gut feeling of the scope.

 

Note that this is on Casablanca and other variants of vFWCL can and probably do exist, but as we are not aware of any other detailed (recent) description, this is what the analysis below is based on.

 

  1. Design time (SDC) is not included in any way except as a dumb catalogue. The starting point seems to be a pre-made service CSAR which is imported to SDC as such. In particular the building of a service including the control loop is not designed using any SDC mechanisms. Using a pre-based service CSAR is of course a fine scenario on its own, but leaves out the design time from demoing and testing, so the coverage will be less.
  2. On run time most of the control loop functionality does not seem to be used either. Simply put, the control loop model does not exist.
    1. On DCAE the flow uses the static bootstrapped instances of VES Collector and TCA and there is no sign of dynamic creation of DCAE service components or any other DCAE resources as part of the vFWCL
    2. Policies are created and manipulated directly using Policy APIs. It is not clear to me if the TCA policy is set dynamically at all or it just uses static configuration for vFWCL from bootstrap as it used to do before in previous releases.
    3. CLAMP is not used at all

 

AFAIK, this is much less than what Dublin control loops are capable of. I would like us to upgrade this demo case to contain the full supported set of components and models. To me this seems like a more fundamental part for https://wiki.onap.org/display/DW/vFirewall+Use+Case+Upgrade than the ones proposed there now. Although those target seem quite similar in spirit and I agree with those in general as well.

 

If a more complex vFWCL variant exists with some or all these features, please share a link to any material about it.

 

-Timo

 

  


t.puha@...
 

Hi,

 

We actually found another variant in https://wiki.onap.org/display/DW/vFW+CDS+Casablanca . That seems to be aligned with the plan in https://wiki.onap.org/display/DW/vFirewall+Use+Case+Upgrade to use CDS for designing the vFW APPC behavior. This seems like a good dimension for enhancing vFW demo case but does not seem to enhance the control loop aspects at all as far I can see.

 

Any views on the scope of vFWCL would still be welcome, especially from the control loop point of view.

 

-Timo

 

 

From: t.puha@... <t.puha@...>
Sent: torstai 16. toukokuuta 2019 17.19
To: 'onap-discuss@...' <onap-discuss@...>; 'PLATANIA, MARCO' <platania@...>
Cc: 'Michal Ptacek' <m.ptacek@...>; 'l.kaihlavirt@...' <l.kaihlavirt@...>
Subject: #ctrl-loop #integration Improvements to vFWCL regarding control loops

 

Hi,

 

Referring to our discussion on this Wednesday’s control loop subcommittee meeting, it felt that we have quite a different view on what is actually included in current vFWCL case. To get some clarity to that, I checked what our guys had actually done with Casablanca vFWCL. See https://gerrit.onap.org/r/gitweb?p=oom/offline-installer.git;a=blob;f=docs/vFWCL-notes.rst;h=690b6dc9ec3c19cc225f6f495c8711b098f91008;hb=refs/heads/casablanca for details and it seems to fit my gut feeling of the scope.

 

Note that this is on Casablanca and other variants of vFWCL can and probably do exist, but as we are not aware of any other detailed (recent) description, this is what the analysis below is based on.

 

  1. Design time (SDC) is not included in any way except as a dumb catalogue. The starting point seems to be a pre-made service CSAR which is imported to SDC as such. In particular the building of a service including the control loop is not designed using any SDC mechanisms. Using a pre-based service CSAR is of course a fine scenario on its own, but leaves out the design time from demoing and testing, so the coverage will be less.
  2. On run time most of the control loop functionality does not seem to be used either. Simply put, the control loop model does not exist.
    1. On DCAE the flow uses the static bootstrapped instances of VES Collector and TCA and there is no sign of dynamic creation of DCAE service components or any other DCAE resources as part of the vFWCL
    2. Policies are created and manipulated directly using Policy APIs. It is not clear to me if the TCA policy is set dynamically at all or it just uses static configuration for vFWCL from bootstrap as it used to do before in previous releases.
    3. CLAMP is not used at all

 

AFAIK, this is much less than what Dublin control loops are capable of. I would like us to upgrade this demo case to contain the full supported set of components and models. To me this seems like a more fundamental part for https://wiki.onap.org/display/DW/vFirewall+Use+Case+Upgrade than the ones proposed there now. Although those target seem quite similar in spirit and I agree with those in general as well.

 

If a more complex vFWCL variant exists with some or all these features, please share a link to any material about it.

 

-Timo