Deployment flavours of VNFs and NSs

[mbredel]

The ETSI specification names deployment flavors of an VNF (and a NS). A deployment flavor references the VDUs (VNFs) and VNFCs (VNFFGs) that are actually deployed. Right now, this is not address in our descriptors.

Question is: Should we limit our descriptors such that they only contain one VNFC (VNFFG)? This would make things much easier. If we support multiple VNFCs( VNFFGs), we also need to implement the deployment flavors.

[shuaibsiddiqui]

The VNFFG is on the NS level and a NS can have multiple VNFFGs depending on how the constituent VNFs are linked up [nsd:vnffgd (0...N)]. I guess we need to take care of multiple VNFFGs anyway. I dont understand what VNFCs (VNFFGs) implies?
A single VNF consists one or more VNFCs ,i.e., [vnfd:vdu:vnfc (1...N)] and the connection between the VNFCs (within that single VNF) is [vnfd:vdu:vnfc:connection_point (1...N)] but not with a VNFFG. Please correct me, if my understanding is wrong. (I am still trying to wrap my head around descriptors :)
Like you mentioned, we could have the deployment flavour on the NS level [nsd:service_deployment_flavor] which points to its constituent VNFs, AND, at VNF-level [vnfd:deployment_flavor:constituent_vdu] which points to its constituent_vnfcs.
But how would restricting ourselves with one VNFC per VNF allows us to avoid implementing deployment flavors?

[mbredel]

I think your understanding is correct ... or at least in line what I've understood :-)

With "VNFCs (VNFFGs)" I just wanted to express, that what is said holds for VNFCs on VNF level, and VNFFGs on NS level. There are deployment flavors on both, VNFD and NSD.

The deployment flavor - best to my understanding - states which VNFC (or VNFFG) is instantiated. Thus, if we have only one VNFC, we don't need the deployment flavor.

I don't see why - in practice - one needs to have multiple VNFCs (or VNFFGs) in a descriptor.

[shuaibsiddiqui]

In my understanding, the deployment flavors allows to have multiple VDUs (with different configs) for the same VNF. For example, a Diamond flavor could specify a VDU with 8 cores and 16GB RAM and a Gold flavor could be associated with a VDU with 4 cores and 8 GB RAM (Just an example). So if a VNF consists of, lets say, two VNFC, one can use the Diamond flavor and other Gold one.

[mbredel]

That is correct. However, in TOSCA (and also HOT) you can parameterize the descriptor (aka template). Then it is always possible to instantiate different flavors at VNF (NS) instantiation time. See also issue #35

The flavors also serve an additional purpose. That is, based on measurements, one starts different flavors. Thus, the flavors can appear in the life-cylce section of the descriptors.

Are you in favor of supporting flavors?

[shuaibsiddiqui]

I think they add flexibility to the description of the VNF and NS.

[mbredel]

Ok - after I gave it some more thoughts I also came to the conclusion that added flexibility is worth the complexity :-) So I will add flavors to the descriptors.

[mbredel]

And now that I discussed with Dario and that I tried to implement the deployments, I tend revise my previous statement. Deployment flavors add a lot of complexity. Moreover, we have to double a lot of information. For example, the min and max values of scale_in_out are stated in the VDU section of the VNFD. But should different deployment flavors have different min/max values for scaling? What happens if the deployment flavor specifies only a subset of VDUs? (That is possible, and nothing prevents you from doing it). Should we then also state a subset of Virtual Links? A subset of Connections Points? Forwarding Graphs? ...

[jbonnet]

Welcome! ;-)
My view is that the general case is really complex to define/implement. We must simplify, as we did in T-NOVA.
As to your questions:

1. should different deployment flavors have different min/max values for scaling: yes, that's the whole idea of flavours. A (service or function) flavour allows providers to have a certain degree of control over the different possibilities developers would want (if totally free to choose; something similar to Amazon's t.micro, t.large, etc.). I think this is a possible approach, specially if aligned with the 'flavours' VIM providers have available (don't know how this could be done, but seems visible);
2. What happens if the deployment flavor specifies only a subset of VDUs? (That is possible, and nothing prevents you from doing it): I see two options:
   2.1 Simply reject the descriptor while validating it;
   2.2 Assume a default flavour, existing or not, for those not having it explicitly;
3. Should we then also state a subset of Virtual Links? A subset of Connections Points? Forwarding Graphs? Yes, since their (non-)existence and characteristics might influence the overall performance;

[mbredel]

Thanks for this input :-) I have some more questions and challenges.

Regarding 1) .. In the VDU section (also according to ETSI), we already have min/max values for scaling. Should we move that to the deployment flavors? Or do the deployment flavors supersede these values? How are these two values related? This is also true for other values in the VDU section, e.g. number of CPUs etc.

I see your point, e.g. with Amazon's flavors . OpenStack Heat has a different concept. But I am not sure if there is a straight forward and simple mapping to the ETSI descriptor.

Regrading 2) ... We then double a lot of information that is also stated in other sections of the descriptor. One possibility I see is that at least a default flavor becomes mandatory (how to state which one is the default?), and ALL the performance-related values go into the deployment flavor. This, however, would be a major change of the descriptors.

FYI: For now, Dario applies your 1.2, he ignores the (non-existing) flavors and instantiates all VDUs, all Virtual Links, etc.