Patent ID: 12244458

DETAILED DESCRIPTION

The present disclosure relates to systems and methods for simplifying the processes to be initiated by a network operator, network manager, or other user who may perform management or administrative operations for controlling a communications network. More particularly, the embodiments of the present disclosure are focused on simplifying the task of changing configuration data for one or more Network Elements (NE) of a network. In conventional systems, a network operator would normally need to have knowledge of an entire configuration for safely making configuration changes without unintentionally impacting other portions of the configuration data. As opposed to replacing the entire configuration, the present disclosure allows a network operator to define which parts of the configuration are to be changed. Then, when these parts of the configuration are replaced, the embodiments of the present disclosure are adapted to prevent any changes (e.g., deletion) to other parts of the configuration.

FIG.1is a diagram illustrating an embodiment of a network10. In this embodiment, the network10includes an infrastructure12that enables a plurality of NEs14-1,14-2, . . . ,14-nto communicate with each other. For example, the NEs14may include any suitable physical component (e.g., switch, router, server, transmitter, receiver, amplifier, etc.) and/or any suitable virtual or software component (e.g., cloud application, Software-as-a-Service (SaaS), etc.). Each NE14is associated with configuration data16-1,16-2, . . . ,16-n, respectively, where the configuration data16may be stored in a local database or datastore or alternatively may be stored in a remote database or datastore. Also, a Network Management System (NMS)18may be arranged in the network10for managing the configuration data16associated with each of the NEs14. In some embodiments, the NMS18may be adapted to operate as a Network Configuration Manager (NCM).

The network10may be adapted to support declarative configuration requests. In other words, a network operator (e.g., using the NMS18) may provide a declaration of a desired state of the network10or a desired state of one or more NEs14. The NMS18, upon receiving this declaration, may be adapted to automatically determine how the configuration data16can be changed or edited as needed to provide the desired state.

For example, the NMS18may include mechanisms to receive an entire configuration in a single operation and then detect differences between a current configuration and a target end-state. As suggested above, conventional systems normally require a full-device configuration to be specified, or, in some cases, may require a complete subtree thereof to be replaced with the new target. The problem with the conventional systems, however, is that any configuration data that is not explicitly specified in the operation would be implicitly deleted (or returned to system default values). The NMS18, according to various embodiments of the present disclosure, is adapted to limit the scope of configuration changes to just the portions of the configuration that the network operator wishes to change and leaves the other portions unchanged.

In many cases, the information included in the configuration data16of each of the plurality of NEs14may go beyond what a network operator may normally know or what the network operator has visibility of. A configuration change request may normally require too much knowledge of the current state. As a result, a network operator, using conventional systems, may simply avoid attempting to replace or remove things that are not of interest. However, with the present embodiments, the network operator may wish to operate on a subset of the configuration data without impacting other coincident peer configuration data under the same data tree. This may include data that is unknown or unavailable. With the present embodiments, the network operator can safely make partial changes without any concerns with respect to other portions outside the realm of interest or knowledge. Thus, knowledge of full configuration data16is not needed, only knowledge of the portion of the configuration data16that the network operator wishes to change.

The NMS18allows the network operator to limit the scope of these declarative operations more precisely to avoid unwanted side effects. In other words, the NMS18may include mechanisms for declarative configuration on a selective or filtered subset of configuration data16of one or more NEs14. In particular, the present disclosure introduces the concept of a user-defined scope for a configuration change/edit operation. Normally, the entire configuration datastore is the target for declarative operations, such that any portions of the configuration that are missing, out-of-date, or outside of access control operations will be deleted, incorrectly edited, or otherwise result in a failure. By providing the network operator with the ability to limit the scope of the configuration change/edit operation to specific parts of the configuration data16, the NMS18can allow more targeted operations to be performed.

FIG.2is a diagram illustrating a simple data structure of configuration data16associated with one of the NEs14shown inFIG.1. In this embodiment, the configuration data16may be divided into a number of subsets. Normally, editing the configuration data16includes replacement the whole configuration. In some embodiments, one or more complete subsets may be replaced.

Again, when configuration changes are made in the conventional systems, any configuration data not explicitly specified is implicitly deleted. In other conventional systems, changing parent (or higher level) subsets may inadvertently impact one or more child subsets. However, the NMS18of the present disclosure may be adapted to specifically target only the subsets (or data access groups) of the configuration data16that are intended to be edited (e.g., added, deleted, changed, etc.). Thus, the NMS18can edit the subsets of the configuration data16as needed.

FIG.3is a diagram illustrating another embodiment of a data structure30of configuration data16that may be associated with each of one or more NEs14. In this embodiment, the data structure30is arranged as a data tree having a plurality of data access groups32. The data access groups32may each include one or more attributes or settings that define the functional aspects of the NE14as included in the associated configuration data16. The data tree of the data structure30includes a hierarchy with parent data access groups (or parent nodes) and child data access groups (or child nodes). The data structure30may also include a root data group34.

It should be noted that the motivation of being able to limit the scope of the replace operation without having to provide a complete target description may be significant in a number of ways. For example, a “deletion by omission” operation (e.g., as is common with conventional systems) makes unintended side-effects very likely. Also, the present disclosure allows a “minimum required configuration” concept, because creating a complete and accurate full description for every configuration operation can be difficult and typically requires a well-designed and thoroughly tested automation. The NMS18provides configuration editing operations that allow for more targeted replace operations.

With gRPC and gNMI, there is normally no way for the network operator to limit the scope of the path provided to a smaller subset to avoid disturbing elements not in the intent. Also, YANG does not explicitly define a way to allow the user to narrow the scope of a root-level operation to only those data models or sub-tree paths that are relevant to the user. In conventional solutions, NETCONF, RESTCONF, gRPC, gNMI, and YANG lack the ability to easily limit the scope of an operation to a known subset (or data access group32) of interest. The embodiments of the present disclosure may be incorporated into NETCONF RESTCONF, gRPC, gNMI, and/or YANG or provided as a modification of these protocols to allow a target scope for modifying configuration data. As described in the present disclosure, the NMS18enables the network operator to apply changes to only a subset (or to only one or more data access groups32) of a configuration without having to worry about the attributes or settings outside the scope of interest.

FIG.4is a block diagram illustrating an embodiment of a Network Management System (NMS)40(e.g., NMS18shown inFIG.1) for editing configuration data (e.g., configuration data16) associated with one or more NEs (e.g., NEs14) in a network (e.g., network10). The NMS40, for example, may be a computer system, a server, a Software Defined Networking (SDN) controller, or other suitable control device, and may be implemented in a control plane of a network system (e.g., network10).

In the illustrated embodiment, the NMS40may be a digital computer that, in terms of hardware architecture, generally includes a processing device42, a memory device44, Input/Output (I/O) interfaces46, a network interface48, and a database50. The memory device44may include a datastore, database (e.g., database50), or the like. It should be appreciated by those of ordinary skill in the art thatFIG.4depicts the NMS40in a simplified manner, where practical embodiments may include additional components and suitably adapted processing logic to support known or conventional operating features that are not described in detail herein. The components (i.e.,42,44,46,48,50) are communicatively coupled via a local interface52. The local interface52may be, for example, but not limited to, one or more buses or other wired or wireless connections. The local interface52may have additional elements, which are omitted for simplicity, such as controllers, buffers, caches, drivers, repeaters, receivers, among other elements, to enable communications. Further, the local interface52may include address, control, and/or data connections to enable appropriate communications among the components42,44,46,48,50.

The processing device42is a hardware device adapted for at least executing software instructions. The processing device42may be any custom made or commercially available processor, a Central Processing Unit (CPU), an auxiliary processor among several processors associated with the NMS40, a semiconductor-based microprocessor (in the form of a microchip or chip set), or generally any device for executing software instructions. When the NMS40is in operation, the processing device42may be adapted to execute software stored within the memory device44, to communicate data to and from the memory device44, and to generally control operations of the NMS40pursuant to the software instructions.

It will be appreciated that some embodiments of the processing device42described herein may include one or more generic or specialized processors (e.g., microprocessors, CPUs, Digital Signal Processors (DSPs), Network Processors (NPs), Network Processing Units (NPUs), Graphics Processing Units (GPUs), Field Programmable Gate Arrays (FPGAs), and the like). The processing device42may also include unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more Application Specific Integrated Circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as “circuitry” or “logic” that is “configured to” or “adapted to” perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc., on digital and/or analog signals as described herein for the various embodiments.

The I/O interfaces46may be used to receive user input from and/or for providing system output to one or more devices or components. User input may be provided via, for example, a keyboard, touchpad, a mouse, and/or other input receiving devices. The system output may be provided via a display device, monitor, Graphical User Interface (GUI), a printer, and/or other user output devices. I/O interfaces46may include, for example, one or more of a serial port, a parallel port, a Small Computer System Interface (SCSI), an Internet SCSI (iSCSI), an Advanced Technology Attachment (ATA), a Serial ATA (SATA), a fiber channel, InfiniBand, a Peripheral Component Interconnect (PCI), a PCI eXtended interface (PCI-X), a PCI Express interface (PCIe), an InfraRed (IR) interface, a Radio Frequency (RF) interface, and a Universal Serial Bus (USB) interface.

The network interface48may be used to enable the NMS40to communicate over a network, such as the network10, the Internet, a Wide Area Network (WAN), a Local Area Network (LAN), and the like. The network interface48may include, for example, an Ethernet card or adapter (e.g., 10BaseT, Fast Ethernet, Gigabit Ethernet, 10 GbE) or a Wireless LAN (WLAN) card or adapter (e.g., 802.11a/b/g/n/ac). The network interface48may include address, control, and/or data connections to enable appropriate communications on the network10.

The memory device44may include volatile memory elements (e.g., Random Access Memory (RAM)), such as Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Static RAM (SRAM), and the like, nonvolatile memory elements (e.g., Read Only Memory (ROM), hard drive, tape, Compact Disc ROM (CD-ROM), and the like), and combinations thereof. Moreover, the memory device44may incorporate electronic, magnetic, optical, and/or other types of storage media. The memory device44may have a distributed architecture, where various components are situated remotely from one another, but can be accessed by the processing device42. The software in memory device44may include one or more software programs, each of which may include an ordered listing of executable instructions for implementing logical functions. The software in the memory device44may also include a suitable Operating System (O/S) and one or more computer programs. The O/S essentially controls the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The computer programs may be adapted to implement the various processes, algorithms, methods, techniques, etc. described herein.

The memory device44may include a datastore used to store data. In one example, the datastore may be located internal to the NMS40and may include, for example, an internal hard drive connected to the local interface52in the NMS40. Additionally, in another embodiment, the datastore may be located external to the NMS40and may include, for example, an external hard drive connected to the Input/Output (I/O) interfaces46(e.g., SCSI or USB connection). In a further embodiment, the datastore may be connected to the NMS40through a network (e.g., network10) and may include, for example, a network attached file server.

Moreover, some embodiments may include a non-transitory computer-readable storage medium having computer readable code stored in the memory device44for programming the NMS40or other processor-equipped computer, server, appliance, device, circuit, etc., to perform functions as described herein. Examples of such non-transitory computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a Read Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), and Electrically Erasable PROM (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by the processing device42that, in response to such execution, cause the processing device42to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

The NMS40may include a device configuration manager54, which may be arranged in hardware, software, firmware, or any combination thereof. As shown, the device configuration manager54is stored in the memory device44and may be implemented as a computer program adapted to enable the processing device42to perform various functions, particularly for editing, changing, or modifying parts or all of the configuration data16that defines functional aspects of one or more NEs14.

The NMS40may be adapted to manage network configuration data for one or more NEs or nodes in a network. For example, when a network (e.g., network10) needs repair, modification, expansion or upgrading, the network operators (e.g., administrators, users, or other managers) can refer to the network configuration management database (e.g., database50) to determine the best course of action. The configuration data may include the locations, IP addresses, network addresses, etc. of all hardware devices (e.g., NEs14), as well as information about the default settings, attributes, programs, versions, updates, etc. installed in the NEs.

In some embodiments, the NMS40may be implemented as a network configuration management system. The NMS40may be adapted to replace data adapted to define functions of each of the NEs14, particularly in the event of a failure. Different NEs14may save different configurations in different formats. Normally, finding this configuration information can be difficult when a particular device has to be replaced. The NMS40may be implemented as a centrally located server within the network10, whereby configuration data can be stored in the database50, according to some embodiments. In this arrangement, the configuration data for each device (e.g., NE14) can be easily downloaded as needed.

The NMS40may include configuration tools can be used for relaunching an NE14after it fails. Also, the NMS40may include configuration management tools adapted to track configuration data on a daily basis to spot any changes in configurations, which could reveal cyber threats and potential failures and adapted for auditing and reporting to enable network operators to easily track information about network components.

According to some implementations, the NMS40may be adapted to enable “declarative configuration” actions. Declarative configuration management refers to the class of tools that allow network operators to declare a desired state of some system (e.g., one or more NEs14, an Elastic Computing Cloud (EC2) Virtual Private Cloud (VPC) (or EC2 VPC), a cloud account, one or more physical machines, or other physical or virtual objects). With respect to declarative configuration management, the NMS40may automatically compare that desired state to the present state, and then automatically update the configurations of the managed system to match the declared state.

FIG.5is a block diagram illustrating an embodiment of a configuration editing system60. In this embodiment, the configuration editing system60includes a User Interface (UI)62adapted to enable a user to enter requests for editing the configuration data of one or more Network Elements (NEs) in a network. Also, the UI62enables the user to provide new configuration data for replacing an existing configuration for a NE. Again, the configuration data is stored with respect to each individual NE and includes attributes, settings, or other suitable information for defining operational or functional aspects of the respective NE to allow the NE to operate within the network. The NE may be a server, switch, router, transmitter, receiver, amplifier, multiplexer, demultiplexer, or other type of physical device used in a network and/or an application, cloud application, Software-as-a-Service (SaaS), or other type of virtual component.

Furthermore, the configuration editing system60includes a configuration supervising device64. In some embodiments, the configuration supervising device64may associated with the NMS40or device configuration manager54shown inFIG.4. The configuration supervising device64is adapted to receive the configuration edit request and new configuration information from the UI62.

In particular, the configuration supervising device64, as shown in this embodiment, includes a configuration edit-request interface66, a targeted configuration editing engine68, and a datastore interface70. The datastore interface70includes a current configuration data retrieval module72and a new configuration data replacement module74. The datastore interface70of the configuration supervising device64is arranged in communication with a datastore device76(e.g., database50) adapted to store one or more configurations78for one or more NEs.

In operation, the configuration edit-request interface66is arranged in communication with the UI62to receive requests to edit the configuration data for one or more NEs. The configuration edit-request interface66also receives an indication of the particular NE (e.g., an amplifier) whose configuration data is to be edited. Also, according to various embodiments of the present disclosure, the configuration edit-request interface66is further adapted to receive an “inclusion filter” from the UI62. The inclusion filter, as described herein, includes information that defines a selected set of data access groups from the plurality of data access groups (e.g., subsets24, data access groups32, etc.) in the configuration data (or other data structure) stored for the intended NE. This selected set of data access groups includes the portions of the configuration data (e.g., attributes, settings, etc.) that are intended to be edited in the current request. The configuration editing system60is adapted to allow only this selected set of data access groups to be edited while ensuring that the data access groups that are excluded from the inclusion filter are left alone (and not deleted or replaced, as is the case in conventional systems). Thus, the data access groups included in the inclusion filter may be new data to be added to the configuration, old data to be deleted, and/or new data to replace old data.

In addition to the inclusion filter, the configuration edit-request interface66is further adapted to receive a “replacement indication” that indicates the data access groups (from the selected set of data access groups defined by the inclusion filter) that are intended to be replaced. Also, the configuration edit-request interface66receives new configuration data that is intended to replace the existing configuration data. Therefore, the configuration supervising device64is adapted to replace the intended configuration data that the user wishes to replace and also delete the data access groups included in the inclusion filter but not included in the replacement indication. Again, attributes or settings in the data access groups that are not listed in the inclusion filter will remain unchanged.

The configuration edit-request interface66receives this input from the UI62and passes it on to the targeted configuration editing engine68. Thus, the targeted configuration editing engine68is adapted to receive a) the configuration edit request, b) the device whose configuration data is to be edited, c) the inclusion filter, d) the replacement indication, and e) the new configuration data for the selected data access groups. Upon receiving this input, the targeted configuration editing engine68is adapted to instruct the current configuration data retrieval module72to retrieve the applicable configuration data78pertaining to the selected NE from the datastore76.

At this point, the targeted configuration editing engine68is adapted to obtain the current state of the configuration data for the selected NE and make appropriated changes based on the information provided by the UI62. Specifically, the targeted configuration editing engine68may replace the old configuration data (e.g., old attributes, settings, etc.) included in the data access groups defined in the replacement indication with the new configuration data (e.g., new attributes, settings, etc.) as well as delete the old configuration data included in the inclusion filter but not specified in the replacement indication. The old configuration data excluded from the inclusion filter are left alone and are neither deleted nor changed. Then the targeted configuration editing engine68sends the edit configuration to the new configuration data replacement module74, which stores the newly modified configuration data in the datastore76.

When the configuration edit request is received by the configuration supervising device64, the configuration supervising device64is adapted to store the modified configuration data78in the datastore76. The new configuration data replacement module74may further be adapted to push this newly modified configuration data to the respective NE. For example, this function of pushing the new configuration based on a configuration request may use NETCONF, RESTCONF, gRPC, gNMI, YANG, or other protocols or Application Programming Interfaces (APIs). In particular, the configuration request (and other input) from the UI62may be a “declarative” request. The configuration supervising device64may be referred to as a class of tools adapted to provide configuration management allowing a user (e.g., network operator) associated with the UI62to declare a desired state of some system or device (e.g., NE). In response, the configuration supervising device64is adapted to automatically compare that desired state to the present state, and then automatically update the configuration data of one or more NEs to match the declared state. The declarative configuration may be compared to a macro where a new configuration is intended to replace (or edit) an existing configuration by adding, deleting, and replacing entries or data access groups of the configuration.

The configuration editing system60is adapted to process a declarative configuration plus an “inclusion filter” as described in the present disclosure. The benefit in this respect is that the network operator may wish to edit certain portions of a configuration but may not know everything that is included in the configuration. The conventional declarative configuration deletes entries that are not in the new configuration. However, the embodiments of the present disclosure add the inclusion filter to allow the user to identify explicitly what is being changed, whereby anything else is left as-is. Thus, the inclusion filter allows the user to identify only the portions that he or she is concerned with and does not require the user to be aware of the entire current state of the existing configuration. The inclusion filter allows the user to list what portions of the configuration to change, whereas, on the other hand, an exclusion filter (of conventional systems) requires the user to list things that are to be left alone, which assumes that the user has full visibility of the entire configuration, which, of course, may be extremely difficult given that some packet switches may have as many as 100 k entries in a configuration.

In a sense, the inclusion filter may be viewed as a filter that limits the extent to which the APIs are replaced. The inclusion filter may be described as a) a user-defined configuration filter, b) a user-defined datastore filter, c) a user-defined data access group filter, etc.

A replace operation in REST or gRPC may provide a path to indicate the level from which the replace operation is to begin. In compliance with this concept, the present disclosure further describes embodiments in which the inclusion filter is added to this path, which may be used to indicate all the subsets (or dependent or child data access groups) under this path to which the replace operation is limited.

According to one example, assume that an amplifier in the network includes a configuration with attributes {a, b, c, d, e, f, g}. In conventional systems, when a user wishes to edit the configuration, the user would provide:Action=replace (or edit)Path=/optical-amplifiers/amplifier[name=‘amp’]Data={a, b, e}
In this case, the result would be the deletion of attributes {c, d, f, g} and the replacement of attributes {a, b, e}.

In contrast, the present disclosure describes systems and methods where the user would provide the following:Action=replace (or edit)Path=/optical-amplifiers/amplifier[name=‘amp’]Filter (inclusion filter)={a, b, c, e, f}Data={a, b, e}
In this case according to the embodiments of the present disclosure, the configuration supervising module64is adapted to provide different results. For example, the result of the above request includes the replacement of {a, b, e}, but the delete function would be limited to only {c, f} since those were in the filter but omitted from the data. The identification of the data to be replaced (e.g., {a, b, e}) may be referred to as the “replacement indication.” Attributes {d, g} (and other attributes that the user may be unaware of) would not be modified.

A copy operation in NETCONF normally refers to a complete datastore. An inclusion filter can be provided, according to the spirit and scope of the present disclosure, to a copy operation in NETCONF, which may be provided via a subtree or some other specification. The inclusion filter in this respect may be adapted to limit the scope of the “copy-config” function to only the listed attributes (e.g., data access groups) provided in the filter.

Similar to the example above, the NETCONF request may be implemented as follows:

<copy-config><source>running</source><target>candidate</target><filter><optical-amplifiers ><amplifier><a/><b/><c/><e/><f></amplifier></optical-amplifiers ></filter>

An edit operation in NETCONF may be provided via Extensible Markup Language (XML) metadata that indicates the elements to be replaced. If provided at a parent level, a filter can be provided under this replace operation that specifically a) excludes child elements from the replace operation, b) uses a new “filtered” operation qualifier that indicates that the elements to be included in the replace operation will be explicitly provided in the descendent content of the configuration, and/or c) include an additional parallel filter in the edit-config to indicate the scope of the edit-config.

FIG.6is a flow diagram illustrating an embodiment of a process80for supervising a configuration editing procedure in a network. The process80includes a step of receiving a request to edit existing configuration data associated with a Network Element (NE) operating in a network, as indicated in block82. The existing configuration data may include a plurality of data access groups, where each data access group includes one or more attributes that characterize functional aspects of the NE. The process80also includes the step of defining a selected set of data access groups from the plurality of data access groups, as indicated in block84. New configuration data for editing a portion of the existing configuration data is received, as indicated in block86. The portion of the existing configuration data to be edited includes a subset of data access groups from the selected set of data access groups. Also, the process80includes replacing the subset of data access groups with the new configuration data while preventing change to the existing configuration data associated with one or more data access groups excluded from the selected set of data access groups, as indicted in block88.

According to additional embodiments, the process may further be defined whereby replacing the subset of data access groups (block88) may include pushing the new configuration data to a datastore associated with the NE. The request described herein may be a declarative operation allowing a user to declare a desired state of the network, where the process80may further include the step of comparing the desired state of the network with a current state of the network defined by at least the existing configuration data associated with the NE. As a result of comparing the desired state with the current state, the process80may further include the step of defining the selected set of data access groups (block84).

Furthermore, the process80may further include the step of deleting the selected set of data access groups omitted from the subset of data access groups. As an example, the NE described in the process80may include one of a server, a router, a transmitter, a receiver, an amplifier, a multiplexer, a demultiplexer, or another suitable device. Also, the selected set of data access groups may be defined in an inclusion filter that includes only the data access groups to be edited with the new configuration data. The data access groups described in the process80may be arranged in a hierarchical data tree having parent data access groups and child data access groups, where the process80may further include defining the selected set of data access groups independent of parent/child relationships in the hierarchical data tree. In addition, the process80may be defined whereby the new configuration data is received with an action request associated with one or more of NETCONF, RESTCONF, gRPC, gNMI, and YANG. The process80in some embodiments may also include defining the selected set of data access groups by targeting data access groups based on a user-defined scope.

In conventional systems, the entire configuration datastore is the target for declarative operations. Therefore, if anything is missing, out-of-date, or outside of access control operations, portions of the configuration may be deleted or incorrectly edited or may result in some other type of failure. One of the novel features of the present disclosure is the introduction of the concept of a user-defined scope for an operation associated with editing configuration data. This allows the user to limit the scope of the configuration editing operation to specific parts of the configuration data, which results in a more targeted replacement operation.

The motivation to limit the scope of the replace operation without having to provide a complete target description has many significant benefits as would be understood by one of ordinary skill in the art. The embodiments of the present disclosure overcome some of the issues with conventional systems, such as the conventional “deletion by omission” scheme that can have unintended negative side-effects. Also, by limiting the scope of replacement, as described in the present disclosure, the present systems and methods may provide a “minimum required configuration” scheme that avoids the difficulty of requiring the user to create a complete and accurate full description for every configuration operation. By pinpointing the portions of the configuration to be edited to provide targeted replacement, the present disclosure does not require a well-designed and thoroughly tested automation process.

From a software perspective, a control plane of an NMS may have a different software architecture than the network element software in the system, but they may both be controlled by the same messaging layer. It may not matter what software architecture is employed, as long as the system has an API that allows a device to establish itself as a trusted source for making configuration changes. Establishing trusted devices may be an action that is driven by the device layer. Otherwise, if a device that should be trusted (e.g., an NMS) requests a configuration change, if it is not recognized by other devices as a trusted source or does not respect that level of trust, then the declarative configuration change may not be performed.

Although the present disclosure has been illustrated and described herein with reference to exemplary embodiments providing various advantages, it will be readily apparent to those of ordinary skill in the art that other embodiments may perform similar functions, achieve like results, and/or provide other advantages. Modifications, additions, or omissions may be made to the systems, apparatuses, and methods described herein without departing from the spirit and scope of the present disclosure. All equivalent or alternative embodiments that fall within the spirit and scope of the present disclosure are contemplated thereby and are intended to be covered by the following claims.