Patent Description:
The disclosure relates to a network management, a method, and a computer-readable medium. Furthermore, the disclosure relates to computer networks, and more particularly, to management of network devices.

A computer network is a collection of interconnected computing devices that can exchange data and share resources. A variety of devices operate to facilitate communication between the computing devices. For example, a computer network may include routers, switches, gateways, firewalls, and a variety of other devices to provide and facilitate network communication.

These network devices typically include mechanisms, such as management interfaces, for locally or remotely configuring the devices. By interacting with the management interface, a client can perform configuration tasks as well as perform operational commands to collect and view configuration data and operations data of the managed devices. For example, the clients may configure interface cards of the device, adjust parameters for supported network protocols, specify physical components within the device, modify routing information maintained by a router, access software modules and other resources residing on the device, and perform other configuration tasks. In addition, the clients may allow a user to view current configuration data and operating parameters, system logs, information related to network connectivity, network activity or other status information from the devices as well as view and react to event information received from the devices.

Network services may be performed by multiple distinct devices, such as routers with service cards and/or dedicated service devices. Such services include connectivity services such as Layer <NUM> Virtual Private Network (L3VPN), Virtual Private Local Area Network Service (VPLS), and Peer to Peer (P2P) services. Other services include network configuration services, such as Dot1q VLAN Service. Network management systems (NMSs) and NMS devices, also referred to as controllers or controller devices, may support these services such that an administrator can easily create and manage these high-level network configuration services. Document <CIT> discloses a system, comprising: one or more computing devices configured to implement a configuration management service that provides a service interface for a plurality of clients, wherein the configuration management service is configured to: for the plurality of clients, generate respective tree representations of a plurality of configuration elements of a distributed application configured to execute on a plurality of execution platforms, wherein each respective tree representation comprises a plurality of non-leaf nodes and a plurality of leaf nodes, wherein each non-leaf node represents a respective collection of configuration elements, and wherein each leaf node represents a respective configuration element comprising one or more values corresponding to designs or deployment architectures of the distributed application; for the plurality of clients, store respective authorization information for one or more nodes of each respective tree representation, wherein the respective authorization information for a particular node includes an indication of at least one respective operation that a respective client of the plurality of clients is allowed to perform on at least one configuration element in the particular node; receive, via the service interface and from a particular client of the plurality of clients, a network request to perform a particular operation on one or more configuration elements of the respective tree representation corresponding to the particular client; in response to (a) the network request received via the service interface to perform the particular operation on the one or more configuration elements in a specified node and (b) a determination that authorization information for the specified node permits the particular operation, initiate the particular operation on the one or more configuration elements in the specified node; and in response to (a) a first request from a first client of the plurality of clients identifying a first node of a tree representation corresponding to both the first client and a second client of the plurality of clients, and (b) a second request from the second client of the plurality of clients identifying a second node of the tree representation corresponding to both the first client and the second client, wherein the first node is not an ancestor node of the second node, and the second node is not an ancestor node of the first node, perform concurrent modifications to the first node and the second node. Document <CIT> discloses a system for configuring network devices, the system comprising: a database comprising: a set of models, representing plurality of network level or device level features as per YANG model, wherein one model corresponds to one device or network level feature in a way agnostic to the device manufacturer or device families; and a plurality of translator files configured to convert an instruction, as represented by the set of models, into network or device specific instructions in a second format. Document <CIT> discloses a method performed by a network management system (NMS) device that manages a plurality of network devices, the method comprising: determining a first set of differences between an existing high-level configuration for the plurality of network devices and a first received high-level configuration for the plurality of network devices; determining a second set of differences between the existing high-level configuration for the plurality of network devices and a second received high-level configuration for the plurality of network devices, wherein the second received high-level configuration is received separately from the first received high-level configuration; translating the first set of differences to a first low-level configuration modification for the plurality of network devices; translating the second set of differences to a second low-level configuration modification for the plurality of network devices; merging the first low-level configuration modification and the second low-level configuration modification to produce a merged low-level configuration modification; and applying the merged low-level configuration modification to low-level configuration of the plurality of network devices. Document <NPL>" discloses information regarding the gRPC Network Management Interface (gNMI), a network management protocol based on the gRPC framework, wherein gNMI supports retrieval and manipulation of state from network elements where the data is represented by a tree structure, and addressable by paths; wherein the gNMI service defines operations for configuration management, operational state retrieval, and bulk data collection via streaming telemetry; and wherein the authoritative gNMI specification is maintained at <NPL>. Document <CIT> discloses a method comprising, by a network management system (NMS) device that manages a plurality of network devices, including a first network device and a second network device configured according to a first high-level configuration: receiving a second high-level configuration for at least the first network device and the second network device; determining a difference between the first high-level configuration and the second high-level configuration; applying a first transformation function, specific to the first network device, to the difference between the first high-level configuration and the second high-level configuration to generate a first low-level configuration change specific to the first device; applying a second transformation function, specific to the second network device, to the difference between the first high-level configuration and the second high-level configuration to generate a second low-level configuration change specific to the second device; configuring the first device with the first low-level configuration change; and configuring the second device with the second low-level configuration change.

Optional embodiments of the invention are described in the dependent claims.

In general, techniques are described for sharing configuration resources for a network device, among multiple applications seeking to modify a configuration of the network device, by associating (e.g., "tagging") properties of configuration resources with application identifiers for the applications. For example, a network management system may store data defining a configuration resource, which models a resource on a network device managed by the network management system. A configuration resource may be created, updated, and deleted using an interface to the network management system. Modifying a configuration resource in any of these ways triggers a corresponding modification, by the network management system, of the corresponding resource on the network device to change the operation of the network device. For example, deleting a configuration resource for a routing policy of a network device causes the network management system to delete the configuration data for that routing policy (i.e., the resource) from the network device.

The network management system may receive configuration requests from multiple different applications that involve the same resource of the same network device. The network management system may enable multiple applications to share the configuration resource for that resource on that network device by allowing the applications to each modify the configuration resource and, more particularly, the properties and respective property values (hereinafter, "property/value pairs") of that configuration resource. To reduce conflict among applications having different configuration intents for the corresponding resource of the network device, the network management system associates each property/value pair with application identifiers for the one or more applications that use the network management system to create or modify the property/value pair. The network management system may use the associations to process subsequent configuration requests for the configuration resource.

The techniques may provide one or more technical advantages that may realize at least one practical application. For example, the techniques may improve network device and network management system utilization and user experience in a multi-tenant and/or multi-administrator context by facilitating sharing while reducing conflicts. In the absence of these techniques, such conflicts could lead to inconsistent configuration of network devices and network instability. As another related example, the techniques may reduce and, in some cases, eliminate conflicts among multiple applications that are using a network management system to configure a resource of a network device. By associating each property/value pair that has been set for a configuration resource with one or more applications, the network management system may (<NUM>) allow multiple applications to configure different property/value pairs for the same configuration resource and may also (<NUM>) allow multiple application to configure the same property/value pair for the same configuration resource, so long as the requested values do not conflict. In addition, the techniques may allow different applications to start and stop the use of a configuration resource at different times.

In an example, a network management system includes a control unit comprising processing circuitry coupled to a memory, wherein the control unit is configured to: receive a configuration request comprising first configuration data for a network device, the first configuration data defining a data structure comprising a first property/value pair; generate, from the first configuration data, a corresponding first path/value pair for the first property/value pair, wherein a path of the first path/value pair uniquely identifies the first path/value pair in an associative data structure; modify the associative data structure based on the first path/value pair; generate, from the associative data structure, a configuration resource comprising second configuration data for the network device, the second configuration data comprising a second property/value pair that corresponds to the first path/value pair; and send the second configuration data to the network device to modify a configuration of the network device.

In an example, a method includes receiving, by a network management system, a configuration request comprising first configuration data for a network device, the first configuration data defining a data structure comprising a first property/value pair; generating, by the network management system from the first configuration data, a corresponding first path/value pair for the first property/value pair, wherein a path of the first path/value pair uniquely identifies the first path/value pair in an associative data structure; modifying, by the network management system, the associative data structure based on the first path/value pair; generating, by the network management system, from the associative data structure, a configuration resource comprising second configuration data for the network device, the second configuration data comprising a second property/value pair that corresponds to the first path/value pair; and sending, by the network management system, the second configuration data to the network device to modify a configuration of the network device.

In an example, a computer-readable medium comprising instructions for causing processing circuitry of a network management system to perform operations comprising: receiving a configuration request comprising first configuration data for a network device, the first configuration data defining a data structure comprising a first property/value pair; generating, from the first configuration data, a corresponding first path/value pair for the first property/value pair, wherein a path of the first path/value pair uniquely identifies the first path/value pair in an associative data structure; modifying the associative data structure based on the first path/value pair; generating, from the associative data structure, a configuration resource comprising second configuration data for the network device, the second configuration data comprising a second property/value pair that corresponds to the first path/value pair; and sending the second configuration data to the network device to modify a configuration of the network device.

<FIG> is a block diagram illustrating an example including network devices of network <NUM> that are managed using a network management system <NUM>, in accordance with one or more techniques of this disclosure. Network devices 14A-<NUM> (collectively, "network devices <NUM>") of network <NUM> include network devices interconnected via communication links to form a communication topology to exchange packetized data. Network devices <NUM> (also referred to herein as "elements" or "managed network devices") may include, for example, routers, switches, gateways, bridges, hubs, edge devices, software defined networking wide area network (SD-WAN) devices, firewalls or other intrusion detection systems (IDS) or intrusion prevention systems (IDP), other network devices, or a combination of such network devices. Communication links interconnecting network devices <NUM> may be physical links (e.g., optical, copper, and the like), wireless, or any combination thereof.

Network <NUM> is shown coupled to public network <NUM> (e.g., the Internet) via communication link <NUM>. Public network <NUM> may include, for example, one or more client computing devices. Public network <NUM> may provide access to web servers, application servers, public databases, media servers, end-user devices, and other types of network resource devices and content. Although network <NUM> is primarily described herein with respect to an enterprise network, the techniques of this disclosure are applicable to other networks, public or private, such as Internet Service Provider (ISP) or Network Service Provider (NSP) networks, cloud service provider networks, and so forth. Network <NUM> may also be referred to herein as a "managed network" in that it is managed at least in part by applications 11A-11N (collectively, "applications <NUM>") using network management system <NUM>.

Network management system <NUM> may be a network appliance, one or more applications executing on one or more real or virtual servers, or a combination thereof. In various examples, network management system <NUM> may be deployed within network <NUM>, at a management site for network <NUM>, a branch office, within a public or private cloud, or some combination thereof. Network management system <NUM> may be vendor-specific, i.e., developed specifically for managing some or all of network devices <NUM> that have been manufactured by a particular vendor. Network management system <NUM> may not be vendor-specific, however, and have the capability to configure devices from multiple different vendors, e.g., using standardized device management protocols. Network management system <NUM> may include or represent an element management system (EMS) or device management system (DMS).

Network management system <NUM> communicates over a network, optionally including network <NUM>, to manage network devices <NUM>. Network management system <NUM> may establish respective persistent or non-persistent communication sessions with one or more of network devices <NUM> for configuration and monitoring. Once network devices <NUM> are deployed and activated, an administrator (not shown) and/or applications <NUM> may interface with network management system <NUM> in order to manage the network devices <NUM> via network management system <NUM>. That is, rather than directly interfacing with network devices <NUM> using, e.g., a network device command line interface (CLI) or device management protocols executed by applications <NUM>, applications <NUM> use network management system <NUM>. This allows operators to centralize control and monitoring of the network devices <NUM> within network management system <NUM>. In addition, network management system <NUM> may provide high-level services that translate high-level intents of the applications <NUM> and operators to low-level network device configurations.

Each of applications <NUM> represent executing instances of one or more applications. Each of applications <NUM> may be executed by a real or virtual server or by an appliance. Each of applications <NUM> may be deployed at a management site for network <NUM>, a branch office, within a public or private cloud, or some combination thereof. Applications <NUM> may include an orchestration platform such as an Openstack, Kubernetes, or other orchestration platform; a network controller or software-defined networking (SDN) controller; a network director or network provisioning platform; a network services provisioning platform; operations/business support system (OSS/BSS); another network management system other than NMS <NUM>; or any other application or system that may invoke NMS <NUM> to configure any of network devices <NUM>.

To manage network system <NUM> including network devices <NUM>, applications <NUM> may interface with network management system <NUM> to remotely monitor and configure network devices <NUM>. For example, applications <NUM> may receive alerts from network management system <NUM> regarding any of network devices <NUM>, view configuration data of network devices <NUM>, modify the configuration data of network devices <NUM>, add new network devices to network <NUM>, remove existing network devices from network <NUM>, or otherwise manipulate the network <NUM> and network devices therein.

Any of applications <NUM> may send configuration requests, e.g., configuration requests 17A-17N, to network management system <NUM> to cause network management system <NUM> to configure network devices <NUM> to specify certain operational characteristics that further the objectives of the application. For example, application 11A may specify for a network device 14A a particular operational policy regarding security, device accessibility, traffic engineering, quality of service (QoS), network address translation (NAT), packet filtering, packet forwarding, rate limiting, or other policies. If necessary, network management system <NUM> translates this operational policy included in a configuration request to configuration data for the network device 14A. Network management system <NUM> uses one or more device management protocols designed for management of configuration data within managed network devices <NUM>, such as the SNMP protocol, Network Configuration Protocol (NETCONF) protocol, a generic remote procedure call (gRPC) network management interface (gNMI), or similar interface/protocol thereof to perform the configuration. In general, NETCONF provides mechanisms for configuring network devices and may use an Extensible Markup Language (XML)-based data encoding for configuration data.

In some examples, network management system <NUM> includes a management interface. The management interface of network management system <NUM> may be configured to accept configuration request in the form of high-level configuration data, or intents, from applications <NUM> (which may be expressed as structured input parameters, e.g., according to the Yet Another Next Generation (YANG) language, which is described in <NPL>). The management interface of network management system <NUM> may also be configured to output respective sets of low-level device configuration data, e.g., device confiRguration additions, modifications, and removals.

In some examples, network management system <NUM> may use YANG modeling for an intent data model and low-level device configuration models. This data may contain relations across YANG entities, such as list items and containers. In some examples, network management system <NUM> may convert a YANG data model into a database model, and convert YANG validations into data validations. Network management system <NUM> may receive data from applications <NUM> representing any or all of create, update, and/or delete actions with respect to the intent data model.

In accordance with techniques of this disclosure, network management system <NUM> includes configuration resources <NUM> for network devices <NUM>. Data stored by or otherwise accessible to NMS <NUM> define each of configuration resources <NUM>. Each of configuration resources <NUM> model a resource on one of network devices <NUM>. As used herein, a resource of a network device is an instance of a data structure that, when configured with appropriate structure, properties, and values and stored to the network device, affects at least one operation of the network device. A resource is configuration data for the network device. A resource may correspond directly to a hardware resource, such as a hardware interface, or may more broadly affect the operation of the network device by configuring a service, policies, or other functions of the network device. Example resources of network devices <NUM> include interfaces, sub-interfaces, network instances such as SD-WANs or virtual private networks, routing instances, zones, routing policies, firewall policies, routing and other protocols, classes of service, accounting, chassis, security, system resources, and others. These various types of resources for network devices <NUM> may correspond to different types of configuration resources <NUM> that model such resources of network devices <NUM> within the network management system <NUM>. Network management system <NUM> may store configuration resources <NUM> for multiple network devices <NUM>.

Any of applications <NUM> may send configuration requests to NMS <NUM> to create, update, or delete configuration resources <NUM>. Modification to a configuration resource in any of the above ways triggers a corresponding modification, by network management system <NUM>, of the resource on a network device to modify the operation of the network device. For example, deleting one of configuration resources <NUM> corresponding to a routing policy of network device 14A causes network management system <NUM> to delete the configuration data for that routing policy (i.e., delete the resource) from network device 14A, and network device 14A will no longer operate according to the deleted routing policy.

Network management system <NUM> may receive multiple configuration requests from different applications <NUM>, the multiple configuration requests involving the same resource of any of network devices <NUM>. For example, application 11A and application 11N may send respective configuration requests 17A, 17N to network management system <NUM> to attempt to configure a configuration resource corresponding to a particular resource of network device 14A, e.g., a resource that configures an interface or routing policy of the network device.

Network management system <NUM> may arbitrate configuration access to configuration resources <NUM> among multiple applications <NUM>. For example, network management system <NUM> may share any of configuration resources <NUM> by allowing multiple applications <NUM> to edit a configuration resource for a network device and, more particularly, the properties and respective property values (hereinafter, "property/value pairs") of that configuration resource. To reduce conflict among applications <NUM> having different configuration intents for the corresponding resource of the network device, network management system <NUM> associates each property/value pair with the one or more applications <NUM> interfacing with network management system <NUM> to create, update, or delete the property/value pair. Network management system <NUM> may use the associations to process subsequent configuration requests, received from any of applications <NUM>, that specify the configuration resource. As described above, creating, updating, or deleting a property/value pair of a configuration resource causes NMS <NUM> to interface to the appropriate one of network devices <NUM> to create, update, or delete the corresponding resource, thereby reconfiguring the network device.

In the example of <FIG>, to associate a path/value pair of a configuration resource with an application, network management system <NUM> may store association data <NUM>. Association data <NUM> may include an associative data structure, such as a table, list, dictionary, or map, having one or more entries. Each entry may associate a unique path/value pair for one of configuration resources <NUM> with one or more application identifiers for respective applications <NUM> that have sent a configuration request to NMS <NUM> to configure a corresponding property/value pair in the configuration resource. The application identifiers may be referred to as "tags" in that an application identifier can be used to effectively tag, in association data <NUM>, a path/value pair with the corresponding one of applications <NUM>.

The techniques may provide one or more technical advantages that may realize at least one practical application. For example, the techniques may improve network devices <NUM> and network management system <NUM> utilization and user experience in a multi-tenant and/or multi-administrator context by facilitating sharing while reducing conflicts, which can lead to inconsistent configuration of network devices <NUM> and network <NUM> instability. As another related example, the techniques may reduce and, in some cases, eliminate conflicts among multiple applications <NUM> that are using a network management system <NUM> to configure a resource of any of network devices <NUM>. By associating each property/value pair that has been set for a configuration resource with one or more applications <NUM>, network management system <NUM> may (<NUM>) allow multiple applications <NUM> to configure different property/value pairs for the same one of configuration resources <NUM> and may also (<NUM>) allow multiple application <NUM> to configure the same property/value pair for the same configuration resource, so long as the requested values do not conflict. In addition, the techniques may allow different applications <NUM> to start and stop the use of any of configuration resources at different times.

<FIG> is a block diagram illustrating an example network management system and network device, in accordance with techniques of this disclosure. Network management system <NUM> manages network device <NUM> using a management protocol, such as NETCONF, for exchanging management protocol messages over a communication link. While described with respect to one particular protocol for managing network devices, e.g., NETCONF, techniques of this disclosure may apply to any network management protocol that provides mechanisms to create, update, and delete the configuration data of network devices.

Network management system <NUM> may be an example of a network management system <NUM> of <FIG> and managed network device <NUM> may be an example of any of network devices <NUM> of <FIG>. In the example illustrated in <FIG>, network management system <NUM> includes control unit <NUM> and network device <NUM> includes configuration interface <NUM> and control unit <NUM>. Each of network management system <NUM> and network device <NUM> may also include network interface cards (not shown).

Each of control unit <NUM> and control unit <NUM> may include processing circuitry that execute software instructions, such as those used to define a software or computer program, stored to a computer-readable storage medium, such as a storage device (e.g., a disk drive, or an optical drive), or memory (such as Flash memory, random access memory or RAM) or any other type of volatile or non-volatile memory, that stores instructions to cause processing circuitry to perform the techniques described herein. Alternatively or additionally, control unit <NUM> and/or control unit <NUM> may comprise dedicated hardware, such as one or more integrated circuits, one or more Application Specific Integrated Circuits (ASICs), one or more Application Specific Special Processors (ASSPs), one or more Field Programmable Gate Arrays (FPGAs), or any combination of one or more of the foregoing examples of dedicated hardware, for performing the techniques described herein.

Control unit <NUM> provides an operating environment for interface <NUM>, service layer <NUM>, and device management layer <NUM>. Generally, service layer <NUM> may be responsible for generating the request in accordance with service models <NUM> and passing the request to management module <NUM> within device management layer <NUM>. Further, device management layer <NUM> may be responsible for constructing a configuration change request in accordance with device models <NUM>. As shown, service layer <NUM> includes service models <NUM>. Device management layer <NUM> includes management module <NUM> and configuration data (CONFIG. DATA) <NUM>.

Interface <NUM> may be provided by an API server <NUM> executed by control unit <NUM>. Interface <NUM> may be a Representational State Transfer (REST) interface that allows applications to issue configuration requests as remote procedure calls (RPCs). Interface <NUM> may be configured to receive configuration data in configuration requests in eXtensible Markup Language (XML), JSON, or plain text formats, for example.

Service models <NUM> may include an application-level model (e.g., Yet Another Next Generation model or simply "YANG model") that may be used to model configuration and state data manipulated by the NETCONF, NETCONF remote procedure calls, and NETCONF notifications. For example, service models <NUM> may receive, via interface <NUM> in a configuration request from an application, an application-level configuration for network device <NUM>. In this example, the application-level configuration may be in accordance with the YANG model. Service models <NUM> may translate the application-level configuration from the YANG model into configuration changes for device models <NUM>.

In some examples, management module <NUM> may receive, via interface <NUM>, a configuration request <NUM> from an application <NUM> that includes the desired configuration for a resource of network device <NUM>. The desired configuration may be in the form an object notation, such as JavaScript Object Notation (JSON). Applications <NUM> may be modified to use interface <NUM>.

A configuration request may also indicate an application identifier for the application that issued the configuration request. An application identifier may be a unique identifier (e.g., a UUID), an application name, or other identifier.

Management module <NUM> represents an example instance of a management application or, more generally, a network management application. Management module <NUM> is one example of a network management module. In one example, management module <NUM> provides mechanisms to install, manipulate, and delete the configuration of network devices of network device <NUM>. Device models <NUM> may include a low level or device level data model (e.g., OpenConfig) that may be used to model configuration change requests. Configuration module <NUM> may be configured to send and/or commit configuration data to network device <NUM>.

Network device <NUM> may be any device having one or more processors and a memory, and that is capable of executing one or more software processes, including configuration engine <NUM>, that operates in accordance with a network management protocol, such as NETCONF. Network device <NUM> stores an "operating" or "running" configuration for the network device in configuration data (CONFIG DATA) <NUM>. That is, configuration data <NUM> determines the operations of network device <NUM> with respect to, e.g., packet forwarding and other services provided by network device <NUM>. Control unit <NUM> of device <NUM> provides an operating environment for configuration engine <NUM> and configuration data <NUM>. Configuration data <NUM> may be stored in a data repository and may each store data in the form of one or more tables, databases, linked lists, radix trees, or other suitable data structure. Configuration data <NUM> may be local or remote to network device <NUM>.

Applications issue configuration requests to interface <NUM> to direct management module <NUM> to manage network device <NUM> in a specified manner, e.g., to modify the configuration of device <NUM>. In accordance with techniques of this disclosure, configuration requests may indicate a configuration resource in order to create, update, or delete a corresponding one or configuration resources <NUM>. A configuration request may invoke an API method and/or endpoint of interface <NUM>. A configuration request may specify a particular network device, e.g., network device 14B, to be configured according to the type of configuration operation (e.g., create, update, or delete) and any configuration data included.

For example, the applications may issue configuration requests that cause NMS <NUM> to modify configuration resources <NUM> that include portions of configuration data <NUM> and ultimately cause NMS <NUM> to deploy the modified configuration data <NUM>, via configuration interface <NUM> and configuration engine <NUM>, to configuration data <NUM> as a running configuration of network device <NUM>. Each configuration resource <NUM> may be associated with a particular network device that is to be configured with the corresponding resource, e.g., network device <NUM> to be configured with one of resources <NUM>. Configuration engine <NUM> may, for example, ensure consistency of configuration data <NUM>, handle configuration commits, and other operations with respect to configuration data <NUM>. Configuration data <NUM> includes resources <NUM>. The term "resources" is defined above.

Configuration interface <NUM> may be provided by an API server executed by control unit <NUM>. Configuration interface <NUM> may be a REST interface that allows network management system <NUM> to send configuration data to network device <NUM> in XML, JSON, or plain text formats, for example. Configuration interface <NUM> may execute one more network management protocols, e.g.. , NETCONF or SNMP, to receive configuration data, including resources, from network management system <NUM>. Configuration engine <NUM> may commit received configuration data, including resources, to configuration data <NUM>.

In accordance with techniques of this disclosure, network management system <NUM> stores, creates, updates, and deletes configuration resources <NUM> for corresponding resources <NUM> of network device <NUM>. Configuration resources <NUM> may be example instances of configuration resources <NUM> of <FIG>. Configuration resources <NUM> may be stored as part of configuration data <NUM> or separately from configuration data <NUM>. A configuration resource is the cumulative configuration created by all applications that have issued configuration requests for the configuration resource, which configuration resource is for configuring the corresponding one of resources <NUM> on network device <NUM>.

Management module <NUM> processes configuration requests received at interface <NUM> and issued by multiple different applications. <FIG> is a flowchart illustrating an example process <NUM> performed by a network management system to process a configuration request, in accordance with techniques of this disclosure. Process <NUM> is described with respect to NMS <NUM> of <FIG>, configuring network device <NUM>, but may performed by other NMSes or other systems (e.g., EMSes, DMSes) to configure other examples of network devices described herein.

Each configuration request indicates configuration data for a configuration resource of configuration resources <NUM> and includes an indication of an application that issued the configuration request. The indication may be an application identifier for the application. In response to receiving a configuration request that includes an indication of configuration data for a configuration resource of network device <NUM>, and also include an application identifier for the application that issued the configuration request (<NUM>), management module <NUM> processes the configuration request to obtain configuration data for the configuration resource (<NUM>). In some cases, the configuration data for the configuration resource is included within the configuration request as JSON, XML, or other structured configuration data. In some cases, the configuration data for the configuration resource must be generated from indications in the configuration request. An example of configuration data for a configuration resource is shown in <FIG> as configuration data of configuration resource <NUM>. The configuration data may include syntax that defines a structure for the configuration resource.

An example of data that may be included in a configuration request is as follows and includes configuration data ("ConfigurationData"), an application identifier ("Application-ID"), a device identifier ("Device-ID"), and a prefix ("Prefix") for identifying a particular resource of the device identified by device identifier:
Application-ID: App_2
Device-ID: <unique-device-identifier>
Prefix: Interfaces/Interface[name=ge-<NUM>/<NUM>/<NUM>]
ConfigurationData: {
"config": {
"mtu": <NUM>,
"name": "ge-<NUM>/<NUM>/<NUM>"
},
"gratuitous-arp": {
"config": {
"reply": true
}
}
}.

In the above example, the "Prefix" can be considered as a resource-name or resource-id which will uniquely identify the resource in the context of one device. If the prefix is not specified, ConfigurationData should contain the full configuration starting from root of configuration hierarchy. Another example of data that may be included in a configuration request is as follows and does not include a value for Prefix:
Application-ID: App_2
Device-ID: <unique-device-identifier>
Prefix: <empty>
ConfigurationData: {
"interfaces": {
"interface": [
{
"name": "ge-<NUM>/<NUM>/<NUM>",
"config": {
"mtu": <NUM>,
"name": "ge-<NUM>/<NUM>/<NUM>"
},
"gratuitous-arp": {
"config": {
"reply": true
}
}
}
]
}
}.

The property/value pairs of configuration data may be arranged according to a hierarchy. For example, the configuration data may include syntax that defines one or more property/value pairs for the configuration resource. The syntax may structure the property/value pairs within a hierarchical data structure, such as a tree, a set of containers, another data structure, or a combination thereof. In the example of configuration data of configuration resource <NUM>, for instance, this configuration data for an interface configuration resource includes a list of containers defined by braces: a "config" container defined that includes three property/value pairs (properties "description", "mtu", and "name"), and a "gratuitous-arp" container that itself include a different "config" container having one property/value pair (property "reply"). This configuration data thus conforms to a tree structure with hierarchical paths.

Management module <NUM> generates path/value pairs from property/value pairs int he configuration data obtained from the configuration request (<NUM>). For example, having obtained the configuration data for the configuration resource, management module <NUM> "flattens out" the configuration data such that each property/value pair has a separate path/value pair, the path being generated in part from the structure of the configuration data. In the example of <FIG>, the configuration data of configuration resource <NUM> is flattened out as shown in the path/value pairs of association data of table <NUM> for configuration resource <NUM>, in particular the Path column and the Value column. Table <NUM> may represent or be included in association data <NUM>. In some cases, the Tags column will not be part of table and will be stored separately, using a tagging feaure, which may be implemented as a separate library or module, and may be implemented as part of an API server. In some cases, the corresponding configuration resource will have the Prefix associated with it in order to shorten the length of paths that need to be stored to table <NUM> (or other forms of association data <NUM>). This prefix will uniquely identify configuration resource for that device.

Management module <NUM> may use various path encoding conventions for generating paths for path/value pairs. For example, management module <NUM> may use gNMI path encoding to convert structured configuration data (e.g., XML or JSON) to a structured path. Again referencing configuration data of configuration resource <NUM> as an example, management module <NUM> may apply path encoding to walk the structure to generate the paths by obtaining prefix strings ("prefixes") for each property/value pair. The "config" container (or node) becomes a prefix for all properties within the container. The names of these properties are appended to the prefix. Thus, the property "name" in the "config" container has partial path "config/name" and value "ge-<NUM>/<NUM>/<NUM>". A higher-layer prefix may be prepended for each path in path/value pairs. This prefix may be based on an identifier for the configuration resource to unique identify each path/value record within a set of path/value records for any configuration resources <NUM> that are stored for network device <NUM> (as well as other network devices, in some instances). In the path/value pairs of association data of table <NUM>, the prefix is "Interfaces/interface[name=ge/<NUM>/<NUM>/<NUM>]". (This prefix has been broken out from the Paths column to improve readability). The configuration resource being configured is an Interface type, and the interface has a unique name among configuration resources having the Interface type. Thus, the full paths for properties "config/name" and "gratuitous-arp/config/reply" are "Interfaces/interface[name=ge/<NUM>/<NUM>/<NUM>]/config/name" and "Interfaces/interface[name=ge/<NUM>/<NUM>/<NUM>]/gratuitous-arp/config/reply", respectively. Similar conventions may apply for other resource types. Any even higher-layer prefix for paths may be a device identifier for network device <NUM> having the corresponding resources <NUM> for configuration resources <NUM>. Management module <NUM> may use other schemes for ensuring uniqueness among paths for each property of configuration resource <NUM>.

Thus, a configuration request can also include an optional "prefix" that will uniquely identify the resource in the configuration data model of a particular device. The configuration request can include prefix; however, the prefix can also be computed as described above.

In some examples, the prefix is a gNMI path that will uniquely identify the resource in the configuration data model. The configuration data model may be any hierarchical data model representing a device configuration. For example, with OpenConfig data model to represent the device configuration, following prefixes can uniquely identify the resources in the configuration hierarchy:.

The example configuration data model below has been annotated with square brackets to denote optional prefix locations in the model for identifying configuration resources. The square bracket may include a comma separated list of <key, value> pairs if the configuration resource at that location in the configuration data model is a collection. The key will be name of key element of collection and the value will be its value. Multiple <key, value> pairs can be present if a collection has a composite key. +--root
+--rw interfaces
+--rw interface* [name]
+--rw name
+--rw config
| +--rw name?
| +--rw type
| +--rw mtu?
+--rw:gratuitous-arp
| +--rw:config
| | +--rw oc-interfaces-jfm-ext:reply? boolean
|
+--rw subinterfaces
| +--rw subinterface* [index] |
+--rw index ->. /config/index
+--rw config
| +--rw index? uint32
| +--rw description? string
| +--rw enabled? boolean
+--rw network-instances
+--rw network-instance* [name]
+--rw name
+--rw fdb
| +--rw config
| | +--rw mac-learning?
| | +--rw mac-aging-time?
| | +--rw maximum-entries?
| | +--rw oc-netinst-jfm-ext:mac-ip-aging-time?.

The full paths are usable as unique keys within association data <NUM> defining an associative data structure, which may be a table in a relational or other database, a dictionary, list, map, or other associative data structure. For purposes of description, this associative data structure will be described as a table in a relational database <NUM>. The table has rows that include the path/value pairs. Table <NUM> includes <NUM> rows for the <NUM> property/value pairs of the configuration data for configuration resource <NUM>.

Database <NUM> may be a relational database, NoSQL database, cloud database, columnar database, object-oriented database, key-value database, other database, or a combination of the above. Database <NUM> may be cloud-based, off-system, or otherwise remotely accessed by NMS <NUM>, or database <NUM> may be stored in a storage device of control unit <NUM>, for example.

Management module <NUM> may iterates (or otherwise process) each of the path/value pairs by comparing each of the generated (flattened-out) path/value pairs for the configuration data for the configuration resource to path/value pairs stored to association data <NUM>. If there is an additional path/value pair to process (YES branch of <NUM>), management module queries association data <NUM> using the path of the additional path/value pair as a lookup key (<NUM>). If an entry for the path does not exist (NO branch of <NUM>), the path/value pair represents a new property/value pair for the configuration resource, and management module <NUM> adds the path/value pair in association with the application identifier to association data <NUM> (<NUM>).

If an entry for the path already exists (YES branch of <NUM>), management module <NUM> determines whether the value in the entry matches the value of the path/value pair being processed (<NUM>). If so (YES branch of <NUM>), there is no conflict for the corresponding property/value that may have already been added by another application, and management module <NUM> adds as association of the application identifier to the path/value pair in the existing entry (<NUM>). The path/value pair in the existing entry may be associated with multiple different application identifiers. As a result of process <NUM> performed with respect to multiple configuration requests issued by multiple different application, association data <NUM> stores unique path/value pairs for configuration resources <NUM> in a structure that facilitates quick key lookup of unique paths for comparison with new paths generated from an incoming configuration request.

Management module <NUM> may in some cases add, update, or delete a value of a path/value pair when the value is not a scalar and is instead an array or list of elements. In such cases, management module <NUM> generates a separate path/value pair for each element in the list of elements in association with the application identifier. For example, for a configuration resource of type AsPathSet having an as-path-set with two elements or "members", management module <NUM> may generate the following in association data <NUM> (prefix shown for ease of description):
Prefix: /routing-policy/defined-sets/bgp-defined-sets/as-path-sets/as-path-set.

Each path may also have one or more associated application identifiers (and/or default identifier) for any applications that have configured the corresponding element. Management module <NUM> may add any new elements to the end of the list. If any application is using any of the elements, the corresponding path/value entry is associated with an application identifier for the application. If no application is using a particular index from the list of elements (e.g. after a deletion), management module <NUM> may delete the corresponding path/value pair from association data <NUM>. However, management module <NUM> may not update the index value:.

In addition, the list should not contain any duplicate items -- an application can use a subset of elements from the list. Management module <NUM> may query association data <NUM> using the list prefix, for example, 'config/as-path-set-member%' and all the list items will be retrieved from association data. Management module <NUM> may update association information based on the scalar values passed by application in the configuration request and matching them against retrieved rows of path/value pairs. Management module <NUM> may create new path/value pairs if required and will contain the next highest index. The above techniques may make it possible to have ownership/sharing of individual values in leaflists, as well as ownership/sharing of values in the object lists. Below is an example of storing an object list eg. Subinterfaces belonging to an interface by flattening out in the associative data structure. Here [index=<NUM>] and [index=<NUM>] are key value pairs that uniquely identify a subinterface instance.

The corresponding config data in the configuration request may be as follows:
{
"interfaces": {
"interface": [
{
"name": "ge-<NUM>/<NUM>/<NUM>",
"subinterfaces": {
"subinterface": [
{
"index": <NUM>,
"config": {
"index": <NUM>,
"ip_address": "<NUM>. <NUM>/<NUM>",
"description": "This sub-interface belongs to App1"
}
},
{
"index": <NUM>,
"config": {
"index": <NUM>,
"ip_address": "<NUM>. <NUM>/<NUM>",
"description": "This sub-interface is shared by App_1 and App_2"
}
}
]
}
}
]
}
}.

If the value in the entry does not match the value of the path/value pair being processed (NO branch of <NUM>), updating the value to the value in the configuration request would overwrite an existing configuration for the corresponding resource configured by another application that may have priority to the resource, at least by virtue of configuring the resource earlier. To avoid upsetting expectations of the other application with respect to network device <NUM> by inadvertent updating of a configuration parameter used by the other application, management module <NUM> may return, via interface <NUM>, an error message in response to the configuration request received at <NUM> to notify the issuing application that the configuration request has failed (<NUM>). In some cases, management module <NUM> may roll back any earlier changes (e.g., at steps <NUM>, <NUM>) made to association data <NUM> in order that the configuration request would have had no effect on configuration resources <NUM> or resources <NUM>. Returning an error ends the iteration through the path/value pairs. In some cases, if the value is different (NO branch of <NUM>), but the path/value of the existing entry is associated only with the default identifier and not any other application identifiers, then rather than sending an error, management module <NUM> may update the value of the existing entry to the new value and may delete the default identifier while adding the application identifier. This reflects an update of the factory default configuration for network device <NUM> and does not upset expectations of another application. The default identifier is described in more detail below.

Management module <NUM> iterates processing the path/value pairs at <NUM> until no further path/value pairs remain (NO branch of <NUM>). At this stage, relevant path/value pairs in association data <NUM> have been created or updated, and management module <NUM> therefore updates the corresponding configuration resource in configuration resource <NUM> to reflect the updated path/value pairs (<NUM>). For example, management module <NUM> may obtain all path/value pairs for the configuration resource and "unflatten" them to generate configuration data for the configuration resource. This may effectively the reverse of the scheme described in step <NUM> and is illustrated in <FIG>, whereby management module <NUM> processes the path and value columns of the entries of association data for the configuration resource, read from table <NUM>, in order to generate configuration resource <NUM>. This includes configuration data for non-scalar values (e.g., lists of elements with their own path/value pairs in association data <NUM>). In some cases, management module <NUM> may generate the configuration resource by merely creating and/or updating property/value pairs of an existing configuration resource based on new and/or updated path/value pairs, rather than fully re-generating the configuration resource.

The configuration resource generated at step <NUM> includes the cumulative configuration data created by all applications that have issued configuration requests for that configuration resource. Management module <NUM> sends configuration data of the configuration resource to network device <NUM> to modify configuration data <NUM> for the device and, more specifically, the corresponding resource of resources <NUM> (<NUM>).

For example, the management module <NUM> may generate configuration data for the configuration resource in structured form, in which case, management module <NUM> may simply send the configuration data as-is to configuration interface <NUM> if configuration interface <NUM> supposed the format (e.g., uses OpenConfig to support JSON, or supports XML, etc.). In some cases, management module <NUM> may translate the configuration data to a vendor-specific format that meets vendor-specific requirements for configuration data and requests/commands sent to configuration interface <NUM>.

<FIG> is a conceptual diagram illustrating examples data structures for managing configuration resources, in accordance with techniques of this disclosure. Configuration resource <NUM> may represent any of configuration resources <NUM> of NMS <NUM>, for example. Configuration resource <NUM> is for configuring a corresponding resource on a network device.

Configuration resource <NUM> may include a device identifier <NUM> for identifier the network device that is to be configured using configuration resource <NUM>. Configuration resources <NUM> includes one or more property/value pairs 402A-402N (collectively, "property/value pairs <NUM>"). Each of property/value pairs <NUM> is configuration data identifying a property of the resource and specifying a value for the property of the resource. Configuration resource <NUM> may be structured data including property/value pairs <NUM> and, in some cases, device identifier <NUM>. Configuration resource <NUM> of <FIG> illustrates a configuration resource having structured data including multiple property/value pairs.

NMS <NUM> uses path/value pairs 404A-404N (collectively, "path/value pairs <NUM>") stored to association data <NUM> to create, update, delete, and arbitrate access to respective property/value pairs 402A-402N of configuration resource <NUM>. As described above with respect to <FIG>, NMS <NUM> may generate or update path/value pair 404A, for instance, using configuration data included in a configuration request or may delete path/value pair 404A based on a delete operation requested in the configuration request for property/value 402A. NMS <NUM> also associates (or "tags") each path/value pair with one or more application identifiers, or with a "default" identifier or "tag" (as shown in association with path/value pair 404A).

In some cases, NMS <NUM> may perform device discovery for network device <NUM> to obtain factory default configuration data. NMS <NUM> may generate configuration resources <NUM> for any resources included in the factory default configuration. As part of generating these configuration resources, NMS <NUM> may also create association data <NUM> in a manner similar to that of processing configuration requests and associate property/value pairs obtained in the factory default configuration with the default identifier. As shown, path/value 404A is associated with the default identifier, which indicates the corresponding property/value pair 402A may have been a factory default configuration and configuration resource <NUM> generated from a factory default resource on network device <NUM>.

NMS <NUM> generates configuration resource <NUM> from path/value pairs <NUM> for configuration resource <NUM>. More specifically, NMS <NUM> may transform each of path/value pairs <NUM> to its corresponding one of property/value pairs <NUM> in configuration resource <NUM> and may, in some cases, conform the generated property/value pairs <NUM> data to a schema for configuration data for configuration resource <NUM>. That is, the configuration data for configuration resource, here shown by property/value pairs <NUM>, may be structured.

NMS <NUM> sends property/value pairs <NUM>, in the form of configuration data <NUM> for configuration resource <NUM>, to network device <NUM>. Configuration module <NUM> may transform configuration data <NUM> to commit configuration data <NUM> and subsequently update configuration data <NUM> with commit configuration data <NUM>. In this way, NMS <NUM> and network device <NUM> update the corresponding one of resources <NUM> for configuration resource <NUM>. Commit configuration data for a resource may be structured data. Configuration data <NUM> in <FIG> for a resource is shown as an example.

<FIG> is a flowchart illustrating an example process <NUM> performed by a network management system to process a configuration request, in accordance with techniques of this disclosure. Process <NUM> is described with respect to NMS <NUM> of <FIG>, configuring network device <NUM>, but may performed by other NMSes or other systems (e.g., EMSes, DMSes) to configure other examples of network devices described herein.

Management module <NUM> receives, via interface <NUM>, a configuration request to delete a configuration resource of configuration resources <NUM>, the configuration request including an indication of an application that issued the configuration request (<NUM>). The indication may be an application identifier for the application. An example of data included in a configuration request to delete a configuration resource is as follows:
Application-ID: App_2
Device-ID: <unique-device-identifier>
Prefix: Interfaces/Interface[name=ge-<NUM>/<NUM>/<NUM>].

As in earlier examples, Prefix may be understood as a resource name or resource identifier that will uniquely identify the configuration resource in the context of the device identified by Device-ID. Application-ID identifies the application that issued the configuration request to delete the configuration resource.

Management module <NUM> may query association data <NUM> to obtain all path/value pairs (along with any associated identifiers) for the configuration resource that are associated with an application identifier for the application (<NUM>). Management module <NUM> may filter all path/value pairs for the configuration resource by application identifier in the query or against the result set for the query, for example.

Management module <NUM> iterates processing (or otherwise processes) the path/value pairs meeting the criteria (<NUM>). If there is another path/value pair to process (YES branch of <NUM>), management module <NUM> determines whether the path/value pair is associated with any additional application identifiers (<NUM>). If not (NO branch of <NUM>), the configuration is not needed and management module <NUM> deletes the path/value pair from association data <NUM> (<NUM>). If there is another application identifier associated (YES branch of <NUM>), then the configuration is still needed by at least one other application, and therefore management module <NUM> deletes, in the association data <NUM> for the path/value pair, only the application identifier for the application that issued the configuration request received at <NUM> (<NUM>). In effect, this remove the tag for that path/value pair.

Management module <NUM> iterates processing the path/value pairs at <NUM> until no further path/value pairs remain (NO branch of <NUM>). At this stage, relevant path/value pairs in association data <NUM> have been deleted, and management module <NUM> therefore updates the corresponding configuration resource in configuration resource <NUM> to reflect the updated path/value pairs (<NUM>). For example, management module <NUM> may obtain all path/value pairs for the configuration resource and "unflatten" them to generate configuration data for the configuration resource. This may effectively the reverse of the scheme described in step <NUM> and is illustrated in <FIG>, whereby management module <NUM> processes the path and value columns of the entries of association data for the configuration resource, read from table <NUM>, in order to generate configuration resource <NUM>. This includes configuration data for non-scalar values (e.g. lists of elements with their own path/value pairs in association data <NUM>). In some cases, management module <NUM> may generate the configuration resource by merely creating and/or updating property/value pairs of an existing configuration resource based on new and/or updated path/value pairs, rather than fully re-generating the configuration resource.

Using a relational database to store path/value pairs with paths as unique keys improves searching the existing paths in the relational database, for queries with different types of match clauses can be executing against relational database. In some examples, use of a relational database and a tagging feature may make it efficient to add, update and remove the path/value and application identifier associations. Still further, the techniques may improve efficiency of determining whether a particular property/value pair is no longer used by any application - absence of any associated application identifier for the corresponding property/value pair means the property/value pair can be removed from the network device configuration. The techniques may permit multiple applications to independently update different path/value pairs for same configuration resource (and corresponding resource on the network device). The techniques may also permit an application to stop using a configuration resource, which allows the NMS <NUM> to remove the configuration so long as the configuration resource is exclusive to that application. The techniques may also permit the NMS <NUM> and network device <NUM> to retain the factory default configuration, at least for so long as no application updates it. The techniques may permit multiple applications to run on top of NMS <NUM> and provide flexibility in defining and using a shared configuration resource by the multiple applications.

In some examples, NMS <NUM> may use configuration resources <NUM> and other techniques described herein to perform disaster recovery. For instance, NMS <NUM> may encode data indicating ownership / association of path/value pairs on network device <NUM>. NMS <NUM> may then subsequently obtain and "regenerate" configuration resources <NUM> from network device <NUM> and also populate association data <NUM> with the path/value pairs and application associations. This may be particularly useful for a situation in which NMS <NUM> fails due, for instance, to a site disaster where NMS <NUM> is hosted to corruption of configuration data <NUM> or database <NUM>.

For the events such as database corruption or site disaster, association data <NUM> for a configuration resource can be encoded into a structure similar to one below, where the path and the list of associated applications can be maintained:
{
"config/name": "Default, App_1, App_2",
"config/mtu ": "App_1, App_2",
"config/description": " App_1 ",
"gratuitous-arp/config/reply": "App_1"
}.

NMS <NUM> may push this structured representation of the association data <NUM> onto network device <NUM>, for each configuration resource. NMS <NUM> may cause this data to be stored as a comment/annotation within configuration data <NUM>, as in the below example:
<rpc>
<edit-config>
<target>
<candidate/>
</target>
<config>
<configuration>
<interfaces>
<interface>
<name>ge-<NUM>/<NUM>/<NUM></name>
< product:comment> {"config/name":"Default, App_1, App_2","config/mtu
":"App_1, App_2","config/description":"
App_1 ","gratuitous-arp/config/reply" : "App_2"} </
comment>
<description>Description for interface ge-<NUM>/<NUM>/<NUM></description>
<mtu><NUM></mtu>
<gratuitous-arp-reply/>
</interface>
</interfaces>
</configuration>
</config>
</edit-config>
</rpc>.

With the above embedded comments, NMS <NUM> can obtain and rebuild configuration resources as well as the association data <NUM> for each path/value pair by processing the comment. For example, NMS <NUM> may issue the following RPC to network device <NUM> to obtain the configuration along with the ownership information from device for interface 'ge-<NUM>/<NUM>/<NUM>'. <rpc
xmlns:product="http://xml. net/ ">
<get-config>
<source>
<running/>
</source>
<filter type="subtree">
<configuration>
<interfaces>
<interface>
<name>ge-<NUM>/<NUM>/<NUM></name>
</interface>
</interfaces>
</configuration>
</filter>
</get-config>
</rpc>.

NMS <NUM> receives reply:
<nc:rpc-reply
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:<NUM>"
xmlns:product="http://xml. net/ ">
<nc:data type="subtree">
<configuration>
<interfaces>
<interface>
<name>ge-<NUM>/<NUM>/<NUM></name>
<product:comment>/* {"config/name":"Default, App_1, App_2","config/mtu
":"App_1, App_2","config/description":" App_1 ","gratuitous-arp/config/reply":"App_2"}
*/</product: comment>
<description>Description for interface ge-<NUM>/<NUM>/<NUM></description>
<mtu><NUM></mtu>
<gratuitous-arp-reply/>
</interface>
</interfaces>
</configuration>
</nc:data>
</nc:rpc-reply>.

NMS <NUM> may convert the comment into JSON, for example, and populate association data <NUM> for the configuration resource accordingly.

In some examples, applications are expected to maintain all configuration needed for a configuration resource. NMS <NUM> may, however, provide a Get option to retrieve a configuration resource. The Get request will include an application identifier, and NMS <NUM> may generate configuration data for the configuration resource, optionally formatted, by obtaining the path/value pairs associated with the application identifier in association data <NUM>.

In some examples that use a gNMI-based interface for interface <NUM>, then after an initial create of a configuration resource, subsequent updates or deletions of property/value pairs do not require sending a full payload. Applications can send only the gNMI path/value pairs in the SetRequest that need to be updated or deleted. The gNMI specification supports an extension proto that can be sent in a SetRequest. The application identifier can be populated in this extension proto.

The techniques may provide one or more technical advantages that are not possessed by server-side apply. For example, the techniques may apply across domains. For example, they do not require Kubernetes or any particular orchestration platform. NMS <NUM> uses a different mechanism for storing and managing associations of property/value pairs and applications, i.e., association data <NUM>. The techniques may more efficiently store data versus server-side apply, since Configuration Resource Definitions (CRD) are stored as an uninterpreted block in etcd.

The techniques may have advantages over server-side apply with respect to conflicts: Once a configuration resource is flattened, simple relational database queries can be performed to see if the value of a path used by another application is being modified. By contrast, server-side apply goes through the managed field of each field manager to identify conflicts. That is, in Kubernetes server-side apply, changes to an object's fields are tracked through a "field management" mechanism. When a field's value changes, ownership moves from its current manager to the manager making the change.

The techniques use association data <NUM> that is less verbose compared to server-side apply, which may make it easier to serialize the association data <NUM> for configuration resources <NUM> to network devices or backup resources, as well as to deserialize such backups and regenerate configuration resources <NUM>. The techniques may provide a more consistent approach for delete compared to server-side apply, i.e., with an explicit delete request instead of sending empty configuration. In the described techniques, the delete operation may be more efficient than server-side apply, for only the application identifiers need to be removed for the application that issued the request. Moreover, deleting a path/value pair from a configuration resource is also efficient: the presence of no associated application identifier for the path/value pair prompts removal.

As a still further advantage, NMS <NUM> may in some examples use a relational database for various storage requirements. There are obvious benefits like indexing, faster queries, etc., using relational databases. For an NMS to leverage the server-side apply of Kubernetes, the NMS would have to use an additional storage system in the form of etcd and also duplicate information into etcd. Kubernetes config-maps and CRDs serve the purpose of storing configuration information for the application but not business data, and relational database are built to handle large volumes of business data. Also, in server-side apply, the association with applications is maintained based on the actor who manages keys (i.e. the keys are owned and shared). By contrast, NMS <NUM> maintains these associations additionally based on the values of the keys/paths (i.e. the values are shared between the applications). As a result, it is possible to have ownership/sharing of values in the leaflist, and it is possible to have ownership/sharing of values in the object lists.

<FIG> is a flowchart illustrating an example operation of a network management system <NUM>, in accordance with one or more techniques of this disclosure. As seen in the example of <FIG>, network management system <NUM> initially may receive a configuration request comprising first configuration data for a network device 14A, the first configuration data defining a data structure comprising a first property/value pair (<NUM>). Next, network management system <NUM> may generate, from the first configuration data, a corresponding first path/value pair for the first property/value pair, wherein a path of the first path/value pair uniquely identifies the first path/value pair in an associative data structure (<NUM>). Next, network management system <NUM> may modify the associative data structure based on the first path/value pair (<NUM>). Next, network management system <NUM> may generate from the associative data structure, a configuration resource comprising second configuration data for network device 14A, the second configuration data comprising a second property/value pair that corresponds to the first path/value pair (<NUM>). Next, network management system <NUM> may send the second configuration data to network device 14A to modify a configuration of network device 14A (<NUM>).

For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combination of such components.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium or a computer-readable transmission medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor, or other processor, to perform the method, e.g., when the instructions are executed. Computer-readable media may include non-transitory computer-readable storage media and transient communication media. Computer readable storage media, which is tangible and non-transitory, may include random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), erasable programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage media" refers to physical storage media, and not signals, carrier waves, or other transient media. Transient communication media, which may occur between components of a single computer system and/or between plural separate computer systems, can include carrier waves, transmission signals or the like, and can be used to convey instructions to a computer and/or processor for execution to cause the instructions to be put into effect.

Therefore, from one perspective, there has been described a method which includes receiving, by a network management system (NMS), a configuration request comprising first configuration data for a network device, the first configuration data defining a data structure comprising a first property/value pair; generating, by the NMS from the first configuration data, a corresponding first path/value pair for the first property/value pair, wherein a path of the first path/value pair uniquely identifies the first path/value pair in an associative data structure; modifying, by the NMS, the associative data structure based on the first path/value pair; generating, by the NMS, from the associative data structure, a configuration resource comprising second configuration data for the network device, the second configuration data comprising a second property/value pair that corresponds to the first path/value pair; and sending, by the NMS, the second configuration data to the network device to modify a configuration of the network device.

Claim 1:
A network management system (<NUM>, <NUM>) comprising:
a control unit (<NUM>) comprising processing circuitry coupled to a memory, wherein the control unit is configured to:
receive (<NUM>) a configuration request (<NUM>, 17A-17N) comprising first configuration data for a network device (<NUM>, 14A-<NUM>), the first configuration data defining a data structure comprising a first property/value pair;
generate (<NUM>), from the first configuration data, a corresponding first path/value pair for the first property/value pair, wherein a path of the first path/value pair uniquely identifies the first path/value pair in an associative data structure;
modify (<NUM>) the associative data structure based on the first path/value pair;
generate (<NUM>), from the associative data structure, a configuration resource (<NUM>) comprising second configuration data for the network device, the second configuration data comprising a second property/value pair that corresponds to the first path/value pair; and
send (<NUM>) the second configuration data to the network device to modify a configuration of the network device.