sonata-nfv / son-schema Goto Github PK

The type of interface has to specified for the connections points of the VNFCs, the VNFs, and the NSs. Right now, we only support strings to name the type "interface" as an interface-type.

We might want to have more interface types like:

• interfaces
• ports
• VPN endpoints

Moreover, we need to a way to configure these interface types.

@mbredel Can you please provide an updated 'simplest-example.son' package? It still has the 'Package Vendor' field, instead of the now correct 'Package Group'.

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.

To be more ETSI compliant we rename the "group" field of the identifier-tuple to "vendor".

As it is, package_content is just an array of items that are part of the package. Since this content is finite, I think it could be improved if more structure could be added, e.g. (WARN: syntax not checked):

...
package_content:
   - service_descriptors:
      name: "sonata-demo.yml"
      content-type: "application/sonata.service_descriptor"
      md5: "a16ce1b66bd6d6916c8f994efca0d778"
    - function_descriptors :
      name: "/iperf-vnfd.yml"
      content-type: "application/sonata.function_descriptor"
       md5: "f99cb6eaf0cd0e4215a724893b55cf5c"
...

This would ease/speed-up interpretation of the package_content, and I guess would have a rather small extra cost.

The TOSCA and the HOT descriptors allow the parameterization of the template. To this end, they specify input sections that contain parameter templates that have to be provided at the instantiation of the template. ETSI also foresees such a feature.

We might want to integrate an input section into our descriptors as well.

To implement the two different kinds of licensing for services and functions we have agreed, I suggest to add somewhere within the descriptors a licence type field. If absent, the service/function would be considered Public (i.e., any developer can reuse it, any customer can buy). If present and with Private value, an extra field should also be present and filled with a URL (i.e., download by a developer or acquisition by a customer will call this URL for validation). I think that in this way we can remove most of the complexity of managing software licences, while allowing for scenarios where that can be taken into account.

What do you think?

For example, in the iperf VND, there is 2 elements with the id mgmt: a virtual_link and a connection_point.

It's a little counter-intuitive as an id generally refers to a unique target (at least in the scope of a file).

In the sonata-demo packages (sonata-demo.son and sonata-demo-docker.son) the version of VNFs (vnd_version) in service descriptor does not match the version of the VNFs in function descriptors. The service descriptor sonata-demo.yml specifies the VNFs "firewall-vnf", "iperf-vnf" and "tcpdump-vnf" with version "0.1", however all this VNF descriptors (firewall-vnfd.yml, iperf-vnfd.yml and tcpdump-vnfd.yml) have the version "0.2".

This causes a problem in matching the correct VNFs specified in the service descriptor, particularly in son-catalogue server which uses the pair <vnf_vendor, vnf_name, vnf_version> for identifying VNFs.

We need to add support for function specific managers (FSMs) to the VNF descriptors. The FSM section might be very similar to the VDU section. Using connection points, the FSMs could be connected to VDUs directly via virtual links.

In addition we need away to express messages and topics to allow the FSMs to interact with the service platform message bus.

For the SLM to identify the correct SSM, we need to have a 'type' field in the NSD. There has to be a limited set of types an SSM can represent. The types are: monitoring, configuration, placement, scaling, task.

It should be more clear if the definition of CPs in the VNFD included an additional tag for notifying possible use of floating IPs

I have included in vTC VNFD this example.

Remove the "ns_" prefix of fields like group, name, etc.

The connection-point parameter contains a reference to the virtual-link that is connected to it (and vice versa). This, however, creates a cyclic reference which is error prone.

Since it is the virtual links that create the VNFC, the reference in the connection points could be removed without any loss of information. However, this would contradict the ETSI NFV specification.

Should we remove the virtual link references form the connection points?

For the FLM to identify the correct FSM, we need to have a 'type' field in the VNFD. There has to be a limited set of types an FSM can represent. The types are: monitoring, configuration, placement, scaling, task.

I notice that the nsr have some fields that are required but not defined in the structure. I have some problems in the nsr validation.

Please have a look here:
https://raw.githubusercontent.com/sonata-nfv/son-schema/master/service-record/nsr-schema.yml

At the end

required: 
  - vendor 
  - name

We can delete it, I’m not sure if we need it.

What do you think?

Docker files appear in the examples as a folder in parallel to service/function descriptors. Do they deserve that? Shouldn't they be subordinate to (i.e., within the folders of) services/functions?

In our schemata, licences (using en-UK) are currently specified as being an array. I don't see any valid use case for such a model, do you? Shouldn't a licence be either absent (so we'd consider the service/function as being 'public') or present, as in

licence:
  type: "public"

or

licence:
  type: "private"
  url: "http://some.url"

(url being mandatory in the case of a private type of licence)

Note the singular form and en-UK licence.

To be more ETSI compliant we rename the "group" field of the identifier-tuple to "vendor".

We plan to have Package catalogue, NS catalogue, VNF Catalogue, etc in the SP-Catalogues. Does this imply that a authorized developer can download a package (including PD, NSD & VNFDs, images, etc.) or a NS (including NSD, VNFD, images, etc) or a VNF (including VNFD, image, etc.) ?

The reason I ask this question is, if the answer to above question is YES then the vm_image path in the VNFD has to be edited according to the VNF.zip file to be returned to the requested developer, as we are not going to send back the complete package.zip file that was prepated by the original/author developer. Thus our efforts to keep the VNFD untouched will go in vain anyway.

This occurs because we receive a complete Network Service package, we extract it and store its contents separately and make them available to other developer as separate entities.

Following up on @tsoenen vnfd_id query in sonata-nfv/son-mano-framework#33, I try to present the issue below:

If we want to keep the PD, NSD, & VNFD untouced within SP, then how do we handle

i) the URIs of the image stored by GK (after extraction, parsing, & validation) ?
a) Do we consider URLs entered by the developer for downloading the image only? That is no need for GK to store the image anywhere. [Note: SP may get errors in the middle of instantiation procedure if the URL is not working.]
b) If the GK stores the image somewhere locally, then do we edit the VNFD to store the info in virtual_deployment_units:vm_image field?

ii) the UUIDs generated by the SP-Catalogues.
a) If the NSD will use the internal ids (vnf_id) to reference different VNFs in it, then what is the purpose of generating UUIDs in the SP-Catalogue? Because the VNFD can be uniquely identified by the naming convention anyway. In case of service instantiation, the GK will fetch the required VNFDs by their unique names as found in the package/NS descriptor.
b) we edit the NSD/VNFD and replace the id field by the generated UUIDs. [Note: If a developer fetches a NSD/VNFD from SP-Catalogue then this id field should be replaced with its unique name value.]

I hope i captured all the aspects of the discussion we had on this topic. Please add if I have missed something out.

In order to make life of people relying on the descriptors easier, we need to come up with a release plan and stable versions. The versions should be the same for all descriptors.

• The references of the Docker images from the VNFDs in the sonata demo package to the files in the package are not correct.
• The VDU references in the VNFDs in the sonata demo package are not correct.

In the VDU section of the VNFD we reference a virtual machine image. Questions are:

• How can we reference a VM image uniquely? A UUID is hard to read/write for humans. A simple name might be ambiguous. In fact we could have the same VNFD referencing the same VM image, but the image might be different - resulting in a different VNF.

JSON Schema foresees a description key for parameters. Each and every parameter should have such a description key that briefly explains the parameters.

@mbredel could you check the field version in nsr and vnfr schema. Currently is "^[0-9]+$" and for example the package descriptor version is "^[0-9-_.]+$"

It should allow versions like 0.1 0.2 1.0 right?

The service descriptor sonata-demo.yml contained in the package sonata-demo.son for Y1 has an incorrect connectivity graph in the virtual_links section. In line 80 it is defined vnf_firewall:output and I think it should be "vnf_tcpdump:output".

bandwidth_units definition is missing in nsd-schema.yml and the validation is failing when bandwidth QoS contraints are added in the NS descriptor. In vnfd-schema is properly defined:
bandwidth_units:
enum:
- "bps" # Bit per second
- "kbps" # Kilobit per second
- "Mbps" # Megabit per second
- "Gbps" # Gigabit per second
- "Tbps" # Terabit per second

I will create a PR to add this missing definition.

The descriptors can become quite complex. It might be beneficial to allow imports of other YAML files to a descriptor. Thus, the descriptor could be split in several files.

• TOSCA allows that already
• Our NS descriptor allows the specification of external virtual link descriptors (VLDs) as well as forwarding graph descriptors (VNFFGs) already. At least theoretically.

Describing monitoring for NS is in a very early stage. It is basically copy-and-paste from the T-NOVA descriptors. Questions are:

• What monitoring parameters do we want to support?
• What is the best way to describe the monitoring parameters?

We are evaluating the vnfd-schema and vfd-schema-metadata decomposition and we think that as a first approach it’s a nice approach. But it’s not aligned with ETSI's information model
(http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf):

• group/name/version initially applied only to our packages. Does this mean that now this applies to all entities?
• Prefixes, field names like "vnf_" are not necessary, maybe the best approach should be to use the same name for the information and data model fields. For example, the deployment_flavours field case, where the data model uses the same name as the information model but it is represented by a complex structure.

If we want to use the same fields aligned with ETSI we propose the use of complex types. For example:

Id (ID (e.g. name) of this VNFD):
Complex structure composed by:

•      UUID
  

•      Group
  

•      Name
  

vendor (Version of the VNF Descriptor):
Complex structure composed by

•      Author
  

•      Vendor
  

•      Creation date
  

version (Version of VNF software, described by the descriptor under consideration):
Complex structure composed by

•      Version
  

•      description
  

Currently the ETSI is working in a new draft of the information model (https://docbox.etsi.org/ISG/NFV/Open/Drafts/IFA015_NFV_Information_Model). We think that if we are aligned with ETSI’s model, it’s much easier to adapt our model to reflect future updates from ETSI definitions.

Could we use an email address for identifying a package author? Or, when we consider users, we could use the user name...? If we use GitHub users, we could reuse those...

What do you think?

see discussion here:sonata-nfv/son-gkeeper#504

Its needed to include the vnf_id specified in the NSD, also in the NSR.
The SLM uses the NSR schema to validate the NSR.
Currently, the service record mentions only this:

"network_functions": [
{
"vnfr_id": "xxxxx"
},
{
"vnfr_id": "yyyyy"
}
],
can vnf_id be added?

Remove the "vnf_" prefix of the fields like group, name, etc.

The VNFD schema contains a lot of parameters coming from the ETSI specification and the T-NOVA implementation. Things like:

• large_pages_required and numa_allocation_policy of the memory section
• SR-IOV (Single Root I/O Virtualization) for NICs and PCI entities
• PCI specific parameters
• many more

Are we going to support these things eventually? Do we really need them in the VNFD - for now at least? Or should we remove them now and focus on things we really implement?

Example service and function descriptor examples are outdated. They should be updated to the new connection points naming conventions, following the rules described in:

sonata-nfv/son-cli#222

Shouldn't this be an object like in network_functions of {ns_id, ns_name, ns_vendor, ns_version} ?

see https://github.com/sonata-nfv/son-schema/blob/master/service-descriptor/nsd-schema.yml#L123

I think that a REST-based micro-service that could validate any of the entities Package/Service/Function could fit well here, what do you think? I'm seeing multiple other micro-services taking advantage of this 'centralised' feature...

We need to add support for service specific managers (SSMs) to the NS descriptors. The SSM section might be very similar to the VNF section. Using connection points, the SSMs could be connected to VNFs directly via virtual links.

In addition we need away to express messages and topics to allow the SSMs to interact with the service platform message bus.

Describing monitoring for VNFs is in a very early stage. It is basically copy-and-paste from the T-NOVA descriptors. Questions are:

• What monitoring parameters do we want to support?
• What is the best way to describe the monitoring parameters?

In the service's 'network_functions', we're using 'vnf_name', 'vnf_vendor' and 'vnf_version', which is a slight inconsistency with the 'name', 'vendor' and 'version' used elsewhere.
Shouldn't we change this also here?

Cleanup the livecycle_events parameter, i.e. things like authentication.

The current examples make an heavy usage of the ':' character in id and ..._ref fields. But the character : can have multiple meanings, for example in the iperf NSD:

        connection_points:
          - connection_point_ref: "ns:input"
            position: 1
          - connection_point_ref: "vnf_iperf:input"
            position: 2

First "ns:input" refers to the element of id ns:input in the current file. So in this case : don't have any signification.
Whereas "vnf_iperf:input" refers to: an element of id input contained in an external file (a VNFD in this case) fetch-able by the vnf_vendor,vnf_name,vnf_version tuple located under the element of vnd_id = vnf_iperf in the current file.

Is my interpretation totally ludicrous or is it voluntary to have multiple way to interpret the connectio_point-ref field ?. It renders the programmability on descriptor a little more complex.

I would propose to ban the : character from any id or name fields so they only appear in the ..._ref fields as a separator. But it may be too risky with the upcoming demo.