ESC uses NETCONF to configure and manage the network and its devices. NETCONF is a network management protocol to install,
manipulate, operate and delete the configuration of network devices. Cisco NSO communicates with ESC using the open NETCONF
protocol and YANG based data models. ESC manages Virtual Network Functions at a device level, and NSO manages the entire network
service lifecycle. Together, they make it a complete orchestration solution that spans across both physical and virtual infrastructure.

Note
|
You can just type esc_nc_cli --user <username> --password <password> command <file name> instead of the complete path for any CRUD operations using the netconf CLI. For more information on CLI, see the Cisco Elastic Services Controller Install and Upgrade Guide.
|
Along with NETCONF notifications, the NETCONF/YANG model also provides operational data. You can run query to get details
such as list of all tenants, networks, and deployments in ESC.
You can create a single NETCONF request to perform multiple actions. For more details, see Netconf Enhancement Request. The
following is a NETCONF request to delete two tenants simultaneously:
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants>
<tenant nc:operation="delete">
<name>abc-mix-tenant1</name>
</tenant>
<tenant nc:operation="delete">
<name>abc-mix-tenant2</name>
</tenant>
</tenants>
</esc_datamodel>
Examples of NETCONF/YANG API are as follows:
NETCONF request to create a Tenant,
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<edit-config>
<source>
<running />
</source>
<config>
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<tenants>
<tenant>
<name>mytenant</name>
</tenant>
</tenants>
</esc_datamodel>
</config>
</edit-config>
</rpc>
An escEvent of type CREATE_TENANT with a status of SUCCESS is sent to NETCONF subscribers once the configuration activation
is completed. This indicates that the activation workflow is complete and the configuration resource is successfully created
in the VIM.
NETCONF notification after a tenant is successfully created:
<notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
<eventTime>2015-05-05T19:38:27.71+00:00</eventTime>
<escEvent xmlns="http://www.cisco.com/esc/esc">
<status>SUCCESS</status>
<status_message>Tenant successfully created</status_message>
<tenant>mytenant</tenant>
<vm_source />
<vm_target />
<event>
<type>CREATE_TENANT</type>
</event>
</escEvent>
</notification>
The operational data (Opdata) for the tenant shows the name and tenant_id. NETCONF request,
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<get>
<filter select="esc_datamodel/opdata/tenants/tenant[name=’mytenant’]" type="xpath" />
</get>
</rpc>
NETCONF response,
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<data>
<esc_datamodel xmlns="http://www.cisco.com/esc/esc">
<opdata>
<tenants>
<tenant>
<name>mytenant</name>
<tenant_id>dccd22a13cc64e388a4b8d39e6a8fa7f</tenant_id>
</tenant>
</tenants>
</esc_datamodel>
</data>
</rpc-reply>
For more details on series of notifications, event failure notifications, and opdata, see the Cisco Elastic Services Controller API Guide.
The NETCONF API configuration and RPC calls are validated. If the request is not valid, it is rejected. The NETCONF API does
not send any error code to NB, unlike REST (for example, REST sends 404 not found error).
A sample error message (rejected request) is as follows
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1">
<rpc-error>
<error-type>application</error-type>
<error-tag>operation-failed</error-tag>
<error-severity>error</error-severity>
<error-path xmlns:esc="http://www.cisco.com/esc/esc"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">/nc:rpc/esc:filterLog</error-path>
<error-message xml:lang="en">Exception from action callback: Error when handling RPC
calls: You can only query up to 30 logs.</error-message>
<error-info>
<bad-element>filterLog</bad-element>
</error-info>
</rpc-error>
</rpc-reply>
The no_gateway attribute allows ESC to create a subnet with the gateway disabled.
In the example below, the no_gateway attribute is set to true to create a subnet without gateway.
<networks>
<network>
<name>mgmt-net</name>
<subnet>
<name>mgmt-net-subnet</name>
<ipversion>ipv4</ipversion>
<dhcp>false</dhcp>
<address>10.0.0.0</address>
<no_gateway>true</no_gateway>
<!-- DISABLE GATEWAY -->
<gateway>10.0.0.1</gateway>
<netmask>255.255.255.0</netmask>
</subnet>
</network>
</networks>
ESC shows OpenStack and VMware vCenter username in its Operational Data section.
The following configuration details are displayed in the Operational Data for,
OpenStack
-
active_vim—displays the value as OpenStack
-
os_auth_url—displays the OpenStack authentication URL
-
admin_role—displays if the OpenStack user is an admin
-
os_tenant_name—displays the tenant
-
os_username—displays the Openstack user
-
member_role—displays if the OpenStack user is a member
VMware vCenter
-
active_vim—displays the value as VMware
-
vcenter_ip—displays the vCentre IP address
-
vcenter_port—displays if the vCentre port
-
vcenter_username—displays the vCentre user