Hello ONAP ARCHCOM and MODCOM members,
please allow me to introduce myself - I am working for Deutsche Telekom
focussing on the automation of the lifecycle of VNFs residing in cloud
infrastructures. Marc Fiedler and Andreas Geissler have asked me to share with
the ONAP community some of our thoughts regarding the modelling of these
entities and I would be very happy to join the discussion here and develop with
you answers to some of the most urgent issues we are facing currently.
I apologize for the lengthy mail but do hope that some of the aspects presented
here might be of interest for the community since they address issues which we
have been facing and for which have not seen desirable solutions yet. So here
goes:
Automation of the lifecycle of VNFs/PNFs
The main objectives when increasing the degree of automation of the lifecycles
of VNFs and PNFs are to:
* increase the agility when introducing changes and updates,
* decrease the cost of operations and
* improve overall service quality.
This approach assumes that the effort involved with the introduction of new
automation tools will be substantially less than when continuing with processes
dominated by manual interventions. VNFs as well as PNFs nowadays consist of a
multitude of different components with following characteristics:
* large number of elements
* huge variety of different technologies
* need for frequent changes (outages, patches, updates, capacity
adjustments, ...)
* complex dependencies between the elements
* mixture of management concepts for both legacy and cloud native solutions
These aforementioned constraints unfortunately all increase the complexity for
automation solutions.
Major issues
Solutions for two major obstacles still must be found to fully reap the
benefits of automation in the VNF/PNF domain:
Integration into the infrastructure environment
Mapping the capabilities of an automation solution onto a specific
environment requires a clear policy of how to model and make use of these assets
(the specifics of the environment being: e.g. distribution of
datacenter and availability zones, supported virtualization technology,
supported optimized network drivers (smart NICs, SR-IOV, DPDK, ...), security
constraints, ... ). Due to the variety of different possible environments the
complexity of the automation solution might explode.
CI/CD integration
Lifecycle management of VNFs/PNFs requires close cooperation
between the solution providers and the telco operators especially in the case
where the responsibilities for the elements change in the course of the
lifecycle (DevOps is only a partial answer if an external vendor provides the
solution but an internal telco DevOps team is responsible for integration and
operations). The customization and configuration of the solutions require a
clear understanding of which parameters are related to the telco specific
context and which parameters are general characteristics of the product.
Modelling guidelines
It is necessary to differentiate between the tools (orchestrators, controllers,
...) executing the instructions which have been captured in a set of abstracted
models, the protocols (REST, api, cli, ...) of how the automation information
is exchanged, the message format of the automation information (TOSCA, yaml,
xml, json, ...) and the schema/semantic information describing the actual
elements and their configuration (ETSI NFV, ...).
[onap.png]
Based on a crude schematic description of the ONAP architecture following
guidelines are regarded to be useful:
* the designer is a tool which allows to describe the desired structure and
interaction of the elements of the VNFs/PNFs
* controllers are specialized tools to manage the lifecycle of elements of
a specific type
* orchestrators coordinate the individual actions of the controllers by
taking care of the dependencies between different elements
* orchestrators should ideally not have to manipulate the configuration
data of the various elements
* controllers receive configuration data from the controller and return
state and endpoint information related to the services which the elements
provide
* elements should ideally all support a basic set of lifecycle states and
transitions (e.g. MTOSI)
* controllers are triggered by the orchestrator to drive an element towards
a desired lifecycle state (intent based API) or are instructed to execute a
specific lifecycle state transition (e.g. start, stop, ...)
* elements need to be mapped to a specific type which allows to identify
which controller to choose for automating its lifecycle
* the dependencies between elements need to be categorized so that the
orchestrator can make use of this information to trigger cascading actions in
the course of changes of individual elements
Specifically:
* due to the differences in virtualization technologies it is probably not
really effective to try to define an abstract model on top of e.g. OpenStack
and Kubernetes since the VNFC artefacts would have to be completely different
(container images, possibly software packages, etc.) - rather standardize the
main attributes for these technology domains from an industry perspective,
introduce appropriate corresponding controllers and allow VNF providers to map
their descriptors against these attributes
* the environment specific aspects of a telco deployment need to be
categorized in more detail so that vendors can highlight which attributes would
relate to the environment specific configuration and thus reduce the overall
complexity by hiding all the other possible customization options
Proposal for Next Steps
The automation tools will become more and more complex if these guidelines
cannot be fulfilled therefore leading to inconsistent and costly
implementations.
Therefore, a close cooperation with VNF/PNF vendors and the ONAP community is
advisable and should address following topics:
* standardization of the lifecycle states and transitions which need to be
supported
* standardization of types of dependencies between required elements of
VNF/PNF solutions
* development of models according to the guidelines mentioned above
* streamlining of the interfaces between the designer, orchestrator and
controllers to reflect the guidelines
I hope the considerations are of interest for the community and would be
delighted to present and discuss the ideas in more detail e.g. via WebEx.
Kind Regards
Bernard Tsai
Deutsche Telekom AG
Technology Architecture & Innovation
Bernard Tsai
T-Online Allee 1, 64295 Darmstadt, Germany
+49 6151 583-7592 (Phone)
+49 171 975-4614 (Mobile)
E-Mail: bernard.t...@telekom.de<mailto:bernard.t...@telekom.de>
www.telekom.com<http://www.telekom.com/>
Life is for sharing.
You can find the obligatory information on
www.telekom.com/compulsory-statement<http://www.telekom.com/compulsory-statement>
Big changes start small - conserve resources by not printing every e-mail.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#3962): https://lists.onap.org/g/onap-tsc/message/3962
Mute This Topic: https://lists.onap.org/mt/27484472/21656
Group Owner: onap-tsc+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
