The Affirmed Service Automation Q&A features answers to post demo questions from the audience on security, network management centralization, and VNFs. Take a look at the below for Dejan and Angela’s perspective on your submitted questions.
Is this product the same as a service orchestrator?
Affirmed: ASAP is designed to help with service creation and automate service configuration procedures. ASAP also does service assurance, once the service has been instantiated. It is not an NFV Orchestrator, although it can work complimentary with a NFVO.
How is this product different from other competitive offerings?
Affirmed: ASAP is truly Network Element agnostic. It support various APIs (NETCONF, REST, SOAP, CLI) and can talk to any managed object/device that supports one of these API interfaces. There is no need for any customer development when a new device is added to the network. In addition, ASAP does not require any agent SW to run on the managed device or require user to know any programing languages.
Is custom development required to support different interfaces/protocols ie. REST/CLI etc.
Affirmed: If a device uses a REST or CLI interface/protocol, the user will simply create the JSON schema or CLI syntax required to execute the specific configuration commands. This can be done by simply copying and pasting the JSON model or CLI syntax in the ASAP schema editor. Only the commands required to execute a particular configuration are required, not the entire REST/CLI configuration schema for the device.
Can you please refer to the security aspects of centralizing all network management in one interface? In this case – if an attacker gains control of ASAP he can control entire network quite easily…
Affirmed: Only the vTransactor is exposed to the managed network elements and the vTransactor will usually reside in the private customer network. The user authentication can be stored and done via an external security entity, so it is not required to have any user authentication information on the vTransactor itself. In addition, the vTransactor functionality can be access via a Northbound GUI, so no network element or user data needs to be stored on the vTransactor itself. The vTransactor also supports rule based account access, so user accessibility can be limited based on network accessibility needs.
What is the process of adding support to a new VNF product (of a new vendor or new product of existing vendor)? What does it require from the vendor?
Affirmed: This will depend on the Northbound API interface/protocol supported by the new VNF. If NETCONF is supported, for a new VNF, the user will have to upload the new YANG schema for that new VNF. If REST or CLI is only supported, the user will have to create the corresponding JSON schema or CLI syntax for the particular VNF. This is done via an API schema GUI and no programing or coding is required.