WO2023249524A1 - Optimizing revert functionality of network device configuration events by a network management system - Google Patents

Abstract

A network management system manages configuration states of features of network devices. Responsive to a revert event, a first group of configuration update events is defined for a first feature based on the configuration update events for the first feature satisfying a rule for having been most recently sent to the network device and for having been sequentially performed on the network device without an intervening update event having been performed on another other features of the network device. The first group of the configuration update events for the first feature are merged into a merged configuration update event for the first group. A revert configuration state operation is generated for the first group to revert the configuration state of the first feature based on the merged configuration update event for the first group. The revert configuration state operation for the first group is sent to the network device.

Description

OPTIMIZING REVERT FUNCTIONALITY OF NETWORK DEVICE CONFIGURATION

EVENTS BY A NETWORK MANAGEMENT SYSTEM

TECHNICAL FIELD

[0001] The present disclosure relates to managing configurations of network devices and, more particularly, to managing network device feature configuration states and associated change events.

BACKGROUND

[0002] A network management system can be configured to manage configuration of features of network devices. One function of a network management system is to track and manage feature configuration change events for each of the managed network devices. Feature configuration change events are also referred to as configuration change events and configuration events for brevity. Feature configuration change events for a network device can include creation of a feature configuration, update of the feature configuration, and deletion of the feature configuration of the network device. Tracking can include storing network device feature configuration change events in a repository which may be in or communicatively connected to the network management system.

[0003] The feature configuration change events stored in the repository can be used for various functionality, such as for displaying feature configuration change events of a network device according to a timeline and for performing reversion from a current feature configuration state of a network device to a previous feature configuration state.

[0004] A feature configuration change event can contain parameters that are to be added, updated, or deleted for the feature at the network device to adapt operation of the feature by the network device. A network device feature can be a networking abstraction that configures a networking protocol such as an Ethemetlnterface, a static route for device communications, a border gateway protocol (BGP) feature in a vendor agnostic manner, etc. The network device features or models can be a key building block in a model driven network management system. Dependencies can exist between network device feature models such as, for example, when a BGP configuration requires use of an Ethemetlnterface, and triggers sending a create event for configuring use of the Ethemetlnterface by the network device followed by sending a create event for configuring use of the BGP by the network device. [0005] A feature configuration for an Ethemetlnterface may contain parameters that define any one or more of, e.g.: interfaceType, link-mode, speed, ip-address, and port. A feature configuration for BGP may contain parameters that define any one or more of, e.g. : type, router-id and neighbours with neighbor ip.

[0006] The network management system may perform revert functionality to revert the feature configuration state of the network device by sending various create, update, or delete event(s) as-needed in order to sequentially revert each of the earlier-stored feature configuration change events for the network device.

[0007] Figure 1 illustrates a timeline of feature configuration change events that are executed for BGP and Ethemetlnterface of a network device. Referring to Figure 1, the network device creates ("C") BGP configuration at time Tl, and then the BGP configuration is updated ("U") at time T2. The network device then creates ("C") an Ethemetlnterface configuration at time T3, updates ("U") the BGP configuration at time T4, updates ("U) the Ethemetlnterface configuration at time T5, and then deletes ("D") the BGP configuration at time T6. In Figure 1, the term T(x) indicates a time when the referenced network device configuration event occurred. The time TO occurs before time Tl, time Tl occurs before time T2, etc.

[0008] An operational problem that arises when reverting the network device feature configuration is that the configuration events performed on the BGP configuration can be dependent upon the configuration events performed on the Ethemetlnterface configuration and vice versa. If the feature configuration is removed or updated in a wrong order or in a way that does not operationally address the feature inter-dependencies, the network device may not accept the removal or updating, and may result in operational failure or other erroneous operation of the remaining feature of the network device.

[0009] One approach for attempting to revert feature configuration of a network device is to incrementally perform reversion one feature configuration change event at a time and in the reverse chronological order in which the feature configuration change events were earlier performed. This approach can be operationally very inefficient and generate large amounts of network traffic and feature configuration changes towards the network device. Moreover, in some situations, the large number of feature configuration changes are perceived by other device(s) connected to that network device as a Denial of Server (DoS) attack on the network device and/or as a failure of the network device due to a potentially large number of connections and/or disconnections being performed by the network device responsive to the lengthy sequence of device configuration events. [0010] Hence there is a need for a more efficient feature configuration revert operation to overcome one or more of these issues.

SUMMARY

[0011] Some embodiments of the present disclosure are directed to method by a network management system for managing configuration states of features of network devices. The method includes maintaining information in a repository indicating configuration change events performed on the features of the network devices. The features includes first and second features. The method responds to determination a revert event being triggered to revert configuration states of the first and second features of a network device to a defined revert time, by defining a first group of configuration update events for the first feature based on the information in the repository indicating the configuration update events for the first feature satisfy a rule for having been most recently sent the network device and for having been sequentially performed on the network device without an intervening update event having been performed on any of the features of the network device other than the first feature. The method merges the first group of the configuration update events for the first feature into a merged configuration update event for the first group. The method generates a revert configuration state operation for the first group which is configured to revert the configuration state of the first feature based on the merged configuration update event for the first group. The method sends the revert configuration state operation for the first group to the network device.

[0012] Some other corresponding embodiments of the present disclosure are directed to a corresponding network management system for managing configuration states of features of network devices. The network management system includes at least one processor and at least one memory storing computer readable program code that when executed by the at least one processor causes the at least one processor to perform operations. Information is maintained in a repository indicating configuration change events performed on the features of the network devices. The features includes first and second features. Operations respond to determination a revert event being triggered to revert configuration states of the first and second features of a network device to a defined revert time, by defining a first group of configuration update events for the first feature based on the information in the repository indicating the configuration update events for the first feature satisfy a rule for having been most recently sent the network device and for having been sequentially performed on the network device without an intervening update event having been performed on any of the features of the network device other than the first feature. Further operation merges the first group of the configuration update events for the first feature into a merged configuration update event for the first group. A further operation generates a revert configuration state operation for the first group which is configured to revert the configuration state of the first feature based on the merged configuration update event for the first group. A further operation sends the revert configuration state operation for the first group to the network device.

[0013] Potential advantages that may be provided by one or more of the embodiments of the present disclosure can include that feature configuration revert functionality uses the stored configuration change events of a network device to determine the reverse chronological order in which the configuration change events need to be performed. However, instead of controlling the network device to separately perform each of the configuration change events in the reverse chronological order, the network management system groups a plurality of the configuration change events for a same feature. Within the group of configuration change events, the network management system merges the configuration change events of the group into a single merged configuration change event that can be used to perform partial feature configuration reversion at the network device. These operations may reduce the number of feature configuration change events which are sent to a network device, and/or may improve robustness of feature configuration revert functionality through analysis of feature configuration dependencies for the network device. [0014] It is noted that aspects described with respect to one embodiment may be incorporated in different embodiments although not specifically described relative thereto. That is, all embodiments and/or features of any embodiments can be combined in any way and/or combination. Moreover, other methods and network management systems according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such other methods and network management systems be included within this description and protected by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Aspects of the present disclosure are illustrated by way of example and are not limited by the accompanying drawings. In the drawings:

[0016] Figure 1 illustrates a timeline of feature configuration change events that are executed for BGP configuration and Ethemetlnterface configuration of a network device; [0017] Figure 2 illustrates a network management system that manages feature configuration change events for various managed network devices, and which is configured to operate according to some embodiments of the present disclosure;

[0018] Figures 3 A and 3B illustrate timelines of network device configuration change events that were performed for a first feature Fl and a second feature F2 of a network device, and groupings of the configuration change events that are selected by a network management system when generating a sequence of revert operations back to time Tx, in accordance with some embodiments of the present disclosure;

[0019] Figure 4 illustrates a timeline of other examples of network device configuration change events that were performed for a first feature Fl, a second feature F2, and a third feature F3 of a network device;

[0020] Figure 5 is a block diagram of a network management system containing components that are configured to operate in accordance with some embodiments of the present disclosure; and

[0021] Figures 6-9 illustrate flowcharts of operations that may be performed by a network management system in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION

[0022] Inventive concepts will now be described more fully hereinafter with reference to the accompanying drawings, in which examples of embodiments of inventive concepts are shown. Inventive concepts may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of various present inventive concepts to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present/used in another embodiment.

[0023] Various embodiments of the present disclosure are directed to reducing the number of feature configuration change events which are sent to a network device, by optimizing feature configuration revert events through analysis of the configuration change events recorded for the network device. These embodiments may be further directed to improving robustness of feature configuration revert functionality through analysis of feature configuration dependencies for the network device. [0024] Examples of network devices include Customer Edge Routers, Provider Edge Routers, switches, Physical Network Function devices (PNFs), Virtual Network Function devices (VNFs), and various end-user devices such as Internet-of-Things (loT) devices (e.g., Internet cameras, thermostats, tablet computers, etc.), smart phones, etc.

[0025] In some embodiments, feature configuration revert functionality uses the stored configuration change events of a network device to determine the reverse chronological order in which the configuration change events need to be performed. However, instead of controlling the network device to sequentially perform each of the configuration change events in the reverse chronological order, the network management system groups a plurality of the configuration change events for a same feature. Within the group of configuration change events, the network management system merges the configuration change events of the group into a single merged configuration change event that can be used to perform partial feature configuration reversion at the network device.

[0026] While the network management system is traversing the reverse chronological order of a first group of the logged configuration change events for a first feature (e.g., BGP) of the network device for merging into a single merged first group configuration change event, when a second feature (e.g., Ethemetlnterface) is encountered the network management system then creates a new separate second group of configuration change events for merging into a single merged second group configuration change event. The term feature refers to a functional operation, such as a communication protocol, operating system function, device application, user applications, etc., which may be performed by instructions executed by at least one processor of a network device.

[0027] Figure 2 illustrates a network management system 200 that manages feature configuration change events for various managed network devices 210, and which is configured to operate according to some embodiments of the present disclosure. Referring to Figure 2, the network management system 200 receives feature configurations from, e.g., one or more client devices. The network management system 200 sends corresponding feature configuration change events to selected ones of the network devices 210 and stores information characterizing the feature configuration change events in a repository in a nonvolatile storage device, which may managed such as by a database, with an association to the selected network device(s) 210. In accordance with some present embodiments, when performing a revert operation for one of the network devices 210, the network management system 200 refers to stored information and groups the feature configuration change events on a feature-by-feature basis for the network device 210, and then for each separate group merges feature configuration change events of the group into a merged feature configuration change event that is used to generate a revert configuration state operation for the first group which is sent to the network device 210 and configured to revert the configuration state of the feature based on the merged configuration update event for the group. Some different example revert configuration state operations are now described with reference to Figures 3 A and 3B.

[0028] Figures 3 A and 3B illustrate timelines of network device configuration change events that were performed for a first feature Fl (e.g., BGP) and a second feature F2 (e.g., Ethernetlnterface) of a network device 210, and groupings of the configuration change events that are selected by a network management system 200 when generating a sequence of revert operations back to time Tx, in accordance with some embodiments of the present disclosure. The example timelines of network device configuration change events illustrated in Figures 3 A and 3B are assumed to cover only from time T24 to the revert time Tx, and not show more recent (subsequent to time T24) configuration change events which have already been successful reverted before reaching the illustrated time T24 in the timelines of Figures 3 A and 3B. Figures 6-9 illustrate flowcharts of operations that may be performed by a network management system in accordance with some embodiments of the present disclosure.

[0029] Referring initially to Figures 3 A, 3B and Figure 6, to manage configuration states of features of a plurality of devices 210, the network management system 200 maintains 600 information in a repository indicating configuration change events performed on the features of the network devices. In the examples of Figures 3 A and 3B, the features include a first feature Fl and a second feature F2.

[0030] The network management system 200 responds to determining 602 a revert event has been triggered to revert configuration states of the first and second features of a network device to a defined revert time (Tx), by defining 604 a first group 300 A, 300B of configuration update events for the first feature Fl based on the information in the repository indicating the configuration update events for the first feature satisfy a rule for having been most recently sent the network device and for having been sequentially performed on the network device without an intervening update event having been performed on any of the features of the network device other than the first feature Fl.

[0031] In the example of Figure 3 A, the network management system 200 groups the sequential feature Fl configuration update ("U") events and delete ("D") event at times T22, T23, and T24, which do not have an intervening other feature F2 configuration change event, into the first group 300A. Similarly in the example of Figure 3B, the network management system 200 groups the sequential feature Fl configuration update ("U") events at times T22, T23, and T24, which do not have an intervening other feature F2 configuration change event, into the first group 300B.

[0032] The network management system 200 merges 606 the first group (300 A in Fig. 3 A, 300B in Fig. 3B) of the configuration update events for the first feature (Fl) into a merged configuration update event for the first group (300A in Fig. 3 A, 300B in Fig. 3B). The network management system 200 then generates 608 a revert configuration state operation for the first group (300A in Fig. 3 A, 300B in Fig. 3B) which is configured to revert the configuration state of the first feature (Fl) based on the merged configuration update event for the first group. The network management system 200 may add the revert configuration state operation for the first group (300A in Fig. 3 A, 300B in Fig. 3B) to a queue of other revert configuration operations to be sent 310 in a single message to the network device 210 for sequential execution, or may presently proceed with sending 610 the revert configuration state operation for the first group (300A in Fig. 3 A, 300B in Fig. 3B) to the network device 210.

[0033] Similarly, the network management system 200 groups the second feature F2 configuration update ("U") events at times T20 and T21, which do not have an intervening first feature Fl configuration change event, into a second group 302. The first feature Fl configuration creation ("C") and update ("U") events at times T16, T17, T18, and T19, which do not have an intervening second feature F2 configuration change event, are grouped into a third group 304. The second feature F2 configuration ("U") events at times T14 and T15, which do not have an intervening first feature Fl configuration change event, are grouped into a fourth group 306.

[0034] As will explained further below with reference to the example revert configuration change operations listed in Table 1, the network management system 200 operates on the individual groups to generate a revert configuration state operation for each group. The revert configuration state operations may be sent in a single message to the network device 210 for sequential execution or may be sent separately when generated. The separate revert configuration state operations responsively trigger reversion of the configuration states of a defined one of the first and second features Fl and F2 while taking into account any interdependency of such changes on the configuration state of the other one of the first and second features Fl and F2. [0035] The revert operations performed by the network management system 200 are now described in further detail with reference to Table 1 and continuing reference to Figures 3A, 3B, and Figures 7-9 in accordance with some embodiments.

[0036] Table 1 lists feature configuration change event state transitions from one state ("From State") to another state ("To State") which is earlier in time, lists corresponding revert configuration state operations sent to the network device, and lists the corresponding operations by the network management system 200 to generate the revert configuration state operations:

TABLE 1

[0037] In Table 1, the term "to-time" refers to a timestamp of the feature configuration change event that is next older than a corresponding grouping of the uninterrupted sequence of feature configuration change events without an intervening other feature configuration change event. The term "toConfig" refers to the merged feature configuration changes at “to- time”, which includes a complete representation of the feature configuration state for the specific network device at the specific "to-time". The term "from -time" refers to the timestamp of the latest device feature configuration change event in the grouping of the uninterrupted sequence of feature configuration change events without an intervening other feature configuration change event. The term "fromConfig" refers to the merged feature configuration changes at the "from-time", which includes a complete representation of the feature configuration state for the specific network device at the specific "from-time". The network device feature may be either “Existing” or “Deleted” at a specified time. The revert configuration state operation sent to the network device to cause the corresponding feature configuration state reversion transitions may include, without limitation, "Create", "Update", and/or "Delete". Content of the revert configuration state operations can be generated by the network management system to revert the configuration state of a feature From State to To State, are shown in column 4 of Table 1 and described below.

[0038] Referring to Figures 3 A and 7, the first revert configuration state operation in Table 1 is now explained to cause a revert transition of the first feature Fl from the deleted “From State” at time T24 of the first group 300A to the existing “To State” at time T19 in the third group 304. Pursuant to Table 1, the operation by the network management system 200 finds the previous create event “C” starting from the to-time of T16 and merge with all update events “U” including the to-time. The operations define 700 the second group 302 of configuration update events for the second feature F2 based on the information in the repository indicating the configuration update events for the second feature F2 satisfy a rule for having been sequentially performed on the network device 210 and occurred next most recent prior to the first group 300 A and without an intervening update event having been performed on any of the features of the network device 210 other than the second feature F2. The network management system 200 determines 702 that the first feature Fl currently has a deleted state at T24 in the network device 210 and had a prior existing state in the network device at a time next most recent prior at T19 to the second group 302. Responsive to the determination 702, operations merge 704 (606 in Fig. 6) the first group 300A of the configuration update events for the first feature Fl into the merged configuration update event for the first group 300A. The operations then generate 706 (608 in Fig. 6) the revert configuration state operation for the first group 300 A as a create first feature Fl operation to cause the network device 210 to create the first feature Fl based on the merged configuration update event for the first group 300A. The operations send 708 (610 in Fig. 6) the revert configuration state operation for the first group 300 A to the network device 210, which may be sent as part of a queued set of operations or may be presently sent.

[0039] Referring to the alternative Figures 3B and 8, the third revert configuration state operation in Table 1 is now explained to cause a revert transition of the first feature Fl from the existing “From State” at time T24 of the first group 300B to the existing “To State” at time T19 in the third group 304. Pursuant to Table 1 and as shown in Figures 3B and 8, the network management system 200 defines 800 the second group 302 of configuration update events for the second feature F2 based on the information in the repository indicating the configuration update events for the second feature F2 satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group 300B and without an intervening update event having been performed on any of the features of the network device other than the second feature F2. The network management system 200 identifies 802 a first feature Fl creation time T16 when a most recent create operation was sent to the network device to create the first feature Fl and which occurred next most recent prior to the second group 302. The network management system 200 identifies 804 a first feature to-time T19 when a most recent update operation was sent to the network device to update the first feature Fl and which occurred next most recent prior to the second group 302. The network management system 200 identifies 806 a first feature from- time T24 when a most recent update operation was sent to the network device to update the first feature Fl and which occurred most recent within the first group 300B. The network management system 200 merges 808 the configuration update events for the first feature Fl from the first feature creation time T16 to the first feature to-time T19, to create a toConfig merged feature update configuration. The network management system 200 merges 810 the configuration update events for the first feature Fl from the first feature creation time T16 to the first feature from-time T24, to create a fromConfig merged feature update configuration. The network management system 200 then generates 812 (608 in Fig. 6) the revert configuration state operation based on a difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration.

[0040] In some embodiments, to generate 812 the revert configuration state operation based on the difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration, the network management system 200 reverts the configuration state of the first feature Fl in the network device 210 from a configuration state of the first feature Fl in the network device 210 at the from -time T24 to a configuration state of the first feature Fl in the network device 210 at the to-time T19.

[0041] Now that the network device 210 has the operational states of the first feature Fl reverted to time T19 and the second feature F2 reverted to time T21, the network management system 200 then operates on the second group 302 to revert the operational states of the second feature F2 to time T15. Referring to the examples of Figures 3B and 9, the network management system 200 defines 900 the second group 302 of configuration update events for the second feature F2 based on the information in the repository indicating the configuration update events for the second feature F2 satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group 300B and without an intervening update event having been performed on any of the features of the network device other than the second feature F2. The network management system 200 defines 902 the third group 304 of configuration update events for the first feature Fl based on the information in the repository indicating the configuration update events for the first feature Fl satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the second group 302 and without an intervening update event having been performed on any of the features of the network device other than the first feature F 1.

[0042] The network management system 200 identifies 904 a second feature creation time when a most recent create operation was sent to the network device 210 to create the second feature F2 and which occurred next most recent prior to the third group 304. The network management system 200 identifies 906 a second feature to-time T15 when a most recent update operation was sent to the network device to update the second feature F2 and which occurred next most recent prior to the third group 304. The network management system 200 identifies 908 a second feature from -time T21 when a most recent update operation was sent to the network device to update the second feature F2 and which occurred most recent within the second group 302. The network management system 200 merges 910 the configuration update events for the second feature F2 from the second feature creation time to the second feature to-time T15, to create a toConfig merged feature update configuration. The network management system 200 merges 912 the configuration update events for the second feature F2 from the second feature creation time to the second feature from -time T21, to create a fromConfig merged feature update configuration. The network management system 200 generates 914 a revert configuration state operation for the second feature F2 based on a difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration. The network management system 200 sends 916 the revert configuration state operation for the second feature F2 to the network device 210 as part of a queued set of operations or may presently send the revert configuration state operation for the second feature F2.

[0043] The second revert configuration state operation in Table 1 is directed to a "delete" feature configuration state transition From State "Existing" to To State "Deleted" through generation of a revert configuration state "Delete" operation. In some embodiments, following the network management system 200 generating the revert configuration state operation for the second feature F2 to the network device 210, if the network management system 200 determined that the first feature Fl had an existing state in the network device 210 while the second group 302 of configuration update events for the second feature F2 were performed on the network device 210 and further had a deleted state in the network device 210 before the second group 302 (which isn’t illustrated in Figures 3A or 3B), the network management system 200 would operate to generate a revert configuration state first feature delete operation to cause the network device 210 to delete the first feature Fl.

[0044] In one illustrate embodiment, the first group of configuration update events includes a plurality of create feature, update feature, and/or delete feature operations, and the second group (302) of configuration update events includes a plurality of create feature, update feature, and/or delete feature operations.

[0045] An example of the first feature Fl may be one of a border gateway protocol, BGP, or an Ethernetlnterface by the network device 210. An example of the second feature F2 may include the other of the BGP or the Ethernetlnterface by the network device 210.

[0046] In another illustrative embodiment, the first group 300B of configuration update events includes at least two update feature operations identifying at least a first neighbor Internet protocol, IP, address and a second neighbor IP address the network device 210 is to add to a first neighbor table used by a first communication protocol. This configuration update performed on the first feature Fl can cause a configuration change for the second feature F2. For example, in this example, the neighbor IP addresses may be first created for the Ethernetlnterface and then associated to the BGP protocol via the BGP feature. The merging 606 of the first group 300B of the configuration update events for the first feature into the merged configuration update event for the first group 300B includes generating the merged configuration update event for the first group to identify the at least first and second neighbor IP addresses the network device 210 is to add to the first neighbor table used by the first communication protocol.

[0047] In a further illustrative embodiment, the second group 302 of configuration update events include at least two update feature operations identifying at least a third neighbor IP address and a fourth neighbor IP address the network device 210 is to add to a second neighbor table used by a second communication protocol which is different than the first communication protocol. The operation to merge 902 the second group 302 of the configuration update events for the second feature F2 into a merged configuration update event for the second group 302 that identifies the at least third and fourth neighbor IP addresses the network device 210 is to add to the second neighbor table used by the second communication protocol. The operation to generate 904 a revert configuration state operation for the second group 302 which is configured to revert the configuration state of the second feature F2 based on the merged configuration update event for the second group 302. Following the network management system 200 sending 610 the revert configuration state operation for the first group 300B to the network device 210. The network management system 200 may sends 906 the revert configuration state operation for the second group 302 to the network device 210 as part of a queued sets of operations or may presently send the operation.

[0048] Further illustrative revert operations are now described with reference to another example shown in Figure 4. Figure 4 illustrates a timeline of other examples of network device configuration change events that were performed for a first feature Fl, a second feature F2, and a third feature F3 of a network device 210. Table 2 below illustrates a chronological order of revert operations performed by the network management system 200 to generate a revert configuration revert the network device feature configurations from time T24 back to time T10 (i.e., revert timestamp T10) in accordance with some embodiments of the present disclosure.

TABLE 2

[0049] Initially, it is noted that the feature F2 configuration change events at times T22, T23, and T24 are not recreated during the revert operation back to time T10 because the change event at time T24 is a "delete" event which deleted the feature F2 configuration from the network device 210, and they occur after an earlier "delete" event at time T13 which is after the revert time T10. Similarly, it is noted that the feature Fl configuration change events at times T20 and T21 are not recreated during the revert operation back to time T10 because the change event at time T21 is a "delete" event which deleted the feature Fl configuration from the network device 210. Accordingly, the feature Fl configuration can be reconstructed from creation at time T2 to time T15 which is before creation of feature F2.

[0050] As a first revert operation in Table 2, a merged create operation for feature F2 is generated by the network management system 200 by generating a merged create operation based on finding previous Create Event ("C") for F2 at time T16 starting from "to-time" and merging with all Update Events ("U") including "to-time" at time T18 and T19. The merged create operation is to be used by the network device 210 to transition feature F2 from state "deleted" to to state "existing" at time T19.

[0051] Example XML snippets configured according to some embodiments for performing revert Operation 1 in Table 2 are now explained. In this example, the first feature F2 is assumed to be BGP and the second feature Fl is assumed to be Ethernetlnterface.

[0052] An example feature configuration Create Event of the network device 210 at T 16 is

<BGP>

<asNumb er>20</ asNumb er>

<neighbors>

<neighbor>

<neighborlp>l .1.1. l</neighborlp>

<remoteAs>l l</remoteAs>

</neighbor> </neighbors> </BGP>

[0053] In the above example, the feature F2 configuration create event for BGP, when it was performed by the network device 210 at T16, configured BGP to understand its relationships with a neighbor device through the remote-as command creating a peer entry in the BGP neighbor table of network device 210 for neighborIP 1.1.1.1. The network management system 200 stored in the repository information characterizing the feature F2 configuration create event at T16. Accordingly, as a first partial step in the revert operation the network management system 200 retrieves the information from the repository to determine that the BGP neighbor table of network device 210 contained neighborIP 1.1.1.1. [0054] An example feature configuration update event of the network device 210 at T18 is

<BGP>

<asNumb er>20</ asNumb er>

<neighbors>

<neighbor>

<neighb orlp>2.2.2.2</ neighb orlp> <remoteAs>22</remoteAs>

</neighbor>

</neighbors> </BGP>

[0055] The network device 210 thereby used the feature F2 configuration update event at T18 to create a peer entry in the BGP neighbor table for neighborIP 2.2.2.2. The network management system 200 stored in the repository information characterizing the feature configuration update event at T18. Accordingly, as a second partial step in the revert operation the network management system 200 retrieves the information from the repository to determine that the BGP neighbor table of network device 210 also contained neighborIP 22.2.2.

[0056] An example feature configuration update event of the network device 210 at T19 is

<BGP>

<asNumb er>20</ asNumb er>

<neighbors>

<neighbor>

<neighborlp>3.3.3 ,3</neighborIp>

<remote As>33 </remote As>

</neighbor>

</neighbors>

</BGP>

[0057] The network device 210 thereby used the feature F2 configuration update event at T19 to create a peer entry in the BGP neighbor table for neighborIP 3.3.3.3. The network management system 200 stored in the repository information characterizing the feature configuration update event at T19. Accordingly, as a third partial step in the revert operation the network management system 200 retrieves the information from the repository to determine that the BGP neighbor table of network device 210 also contained neighborIP 3.3.3.3.

[0058] An example merged create operation for feature F2 as the output of merging the events at T16, T18, T19 by the network management system 200 is

<BGP>

<asNumb er>20</ asNumb er>

<neighbors>

<neighbor>

<neighborlp>l .1.1. l</neighborlp>

<remoteAs>l l</remoteAs> </neighbor>

<neighbor>

<neighb orlp>2.2.2.2</ neighb orlp>

<remoteAs>22</remoteAs>

</neighbor>

<neighbor>

<neighborlp>3.3.3 ,3</neighborIp>

<remote As>33 </remote As>

</neighbor>

</neighbors>

</BGP>

[0059] The network management system 200 can then use this single merged create operation for feature F2 for the network device 210 to create and configure the BGP neighbor table for feature F2 to include neighborlp 1.1.1.1, neighborlp 2.2.2.2, and neighborlp 3.3.3.3, corresponding to revert operation 1 in Table 2.

[0060] The network management system 200 then performs revert Operation 2 in Table 2 to generate a merged create operation for feature Fl to transition from state "deleted" to to state "existing", based on finding previous Create Event ("C") for Fl at time T2 starting from "to-time" and merging with all Update Events ("U") including "to-time" at T11 (update), T12 (update), T14 (update), and T15 (update) characterized by the information retrieved from the repository, using a similar process to that described for revert operation 1 in Table 2.

[0061] The network management system 200 then performs revert Operation 3 in Table 2 to generate a merged update operation for feature F2 to transition from state "existing" to to state "existing", based on the revert operations of determining a difference between a (merge of the feature F2 configurations at T 16, T 18, and T19) and the feature F2 configuration at T16).

[0062] Example XML snippets configured according to some embodiments for performing Operation 3 in Table 2 are now explained.

[0063] A merge of the feature configurations of the network device 210 at T16, T18, T19 following:

<BGP>

<asNumb er>20</ asNumb er>

<neighbors> <neighbor>

<neighborlp>l .1.1. l</neighborlp>

<remoteAs>l l</remoteAs>

</neighbor>

<neighbor>

<neighb orlp>2.2.2.2</ neighb orlp>

<remoteAs>22</remoteAs>

</neighbor>

<neighbor>

<neighb orlp>3.3.3.3 </ neighb orlp>

<remote As>33 </remote As>

</neighbor>

</neighbors>

</BGP>

[0064] The feature configuration of the network device 210 at T16 is

<BGP>

<asNumb er>20</ asNumb er>

<neighbors>

<neighbor>

<neighborlp> 1.1.1.1 </neighbor!p>

<remoteAs>l l</remoteAs>

</neighbor>

</neighbors>

</BGP>

[0065] The following XML snippet performs the difference between the merge of feature configurations at T16, T18, T19 with that of T16. It is noted that the XML attribute action ’’remove” is network device 210 specific and its operation can differ depending on the type of network device 210. In this example, the network device 210 will react on the XML attribute action of ’’remove” and remove the specified “neighbors”.

<BGP>

<asNumb er>20</ asNumb er>

<neighbors>

<neighbor action="remove">

<neighb orlp>2.2.2.2</ neighb orlp> <remoteAs>22</remoteAs>

</neighbor>

<neighbor action="remove">

<neighborlp>3.3.3 ,3</neighborIp>

<remote As>33 </remote As>

</neighbor>

</neighbors>

</BGP>

[0066] Once this request has been sent by the network management system 200 to the network device 210, the configuration becomes reverted with neighbors 2.2.2.2 and 3.3.3.3 removed from the neighbor list of feature F2 in the network device 210.

[0067] The network management system 200 then performs revert Operation 4 in Table 2 to generate a merged update operation for feature F3 to transition from state "existing" to to state "existing", based on the revert operations determining a difference between a (merge of the feature F3 configurations at Tl, T5, T6, T7, T8, T9, and T10) and a (merge of feature F3 configurations at Tl, T5, T6, T7, T8, T9, T10, and T17).

[0068] The network management system 200 then performs revert Operation 5 in Table 2 to delete feature F2 to revert the network node 210.

[0069] The network management system 200 then performs revert Operation 6 in Table 2 to generate a merged update operation for feature Fl to transition from state "existing" to to state "existing", based on the revert operations of a merge of feature Fl configurations at T2, Ti l, and T12, the determine the difference with a merge of feature Fl configurations at T2, Ti l, T12, T14, and T15.

[0070] The network management system 200 then performs revert Operation 7 in Table 2 to transition from state "deleted" to to state "existing", by causing the network node 210 to create and configure feature F2 at time T4.

[0071] The network management system 200 then performs revert Operation 8 in Table 2 to generate a merged update operation for feature Fl to transition from state "existing" to to state "existing", based on the revert operations of obtaining the feature Fl configuration at time T2, and then determining the difference with a merge of feature Fl configurations at T2, Ti l, and T12. The network management system 200 communicates the revert configuration state operation result to change the feature configurations of the network node 210.

[0072] In this manner, the network management system 200 performs revert configuration state operations on the network device 210 while ensuring that any inter-device feature relations are properly performed, and while optimizing the flow by grouping and merging feature configuration revert events belonging to the same device feature.

[0073] Figure 5 is a block diagram of a network management system 200 containing components that are configured to operate in accordance with some embodiments of the present disclosure.

[0074] Referring to Figure 5, the network management system 200 includes one or more network interfaces 520 (referred to as "network interface" for brevity), one or more processors 500 (referred to as "processor" for brevity), and one or more memories 510 (referred to as "memory" for brevity) storing instructions 512. The memory 510 may store a repository 514 of information indicating network device configuration change events performed on features of network devices. The network interface 520 may be configured to communicate through a wired interface, e.g., Ethernet, and/or wireless interface, e.g., wireless transceiver, according to one or more proprietary protocols and/or industry standardized protocols. The processor 500 may include one or more data processing circuits, such as a general purpose and/or special purpose processor (e.g., microprocessor, digital signal processor, field programmable gate array, etc.) that may be collocated or distributed across one or more networks. The processor 500 is configured to execute the instructions 512 in the memory 510, described below as a non-transitory computer readable medium, to perform some or all of the operations and methods that are described above for one or more of the embodiments of a network management system disclosed herein.

[0075] In the above-description of various embodiments of the present disclosure, it is to be understood that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense expressly so defined herein.

[0076] The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various aspects of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions. [0077] The terminology used herein is for the purpose of describing particular aspects only and is not intended to be limiting of the disclosure. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items. Like reference numbers signify like elements throughout the description of the figures.

[0078] The corresponding structures, materials, acts, and equivalents of any means or step plus function elements in the claims below are intended to include any disclosed structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosure in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the disclosure. The aspects of the disclosure herein were chosen and described in order to best explain the principles of the disclosure and the practical application, and to enable others of ordinary skill in the art to understand the disclosure with various modifications as are suited to the particular use contemplated.

Claims

Claims:

1. A method by a network management system (200) for managing configuration states of features of network devices (210), the method comprising: maintaining (600) information in a repository (514) indicating configuration change events performed on the features of the network devices, the features comprising first (Fl) and second (F2) features; and responding to determination (602) a revert event being triggered to revert configuration states of the first and second features of a network device to a defined revert time (Tx), by: defining (604) a first group (300 A, 300B) of configuration update events for the first feature (Fl) based on the information in the repository indicating the configuration update events for the first feature satisfy a rule for having been most recently sent the network device and for having been sequentially performed on the network device without an intervening update event having been performed on any of the features of the network device other than the first feature (Fl); merging (606) the first group (300 A, 300B) of the configuration update events for the first feature (Fl) into a merged configuration update event for the first group (300 A, 300B); generating (608) a revert configuration state operation for the first group (300 A, 300B) which is configured to revert the configuration state of the first feature (Fl) based on the merged configuration update event for the first group; and sending (610) the revert configuration state operation for the first group (300 A, 300B) to the network device.

2. The method of Claim 1, further comprising: defining (700) a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature (F2) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300 A) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2); and responsive to determining (702) the first feature (Fl) currently has a deleted state (T24) in the network device and had a prior existing state in the network device at a time next most recent prior (T19) to the second group (302), performing (704) the merging (606) of the first group (300A) of the configuration update events for the first feature (Fl) into the merged configuration update event for the first group (300 A), performing (706) the generating (608) the revert configuration state operation for the first group (300 A) as a create first feature (Fl) operation to cause the network device to create the first feature (Fl) based on the merged configuration update event for the first group (300 A), and performing (708) the sending (610) of the revert configuration state operation for the first group (300 A) to the network device.

3. The method of any of Claims 1 to 2, further comprising: defining (800) a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature (F2) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300B) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2); identifying (802) a first feature (Fl) creation time (T16) when a most recent create operation was sent to the network device to create the first feature (Fl) and which occurred next most recent prior to the second group (302); identifying (804) a first feature to-time (T19) when a most recent update operation was sent to the network device to update the first feature (Fl) and which occurred next most recent prior to the second group (302); identifying (806) a first feature from-time (T24) when a most recent update operation was sent to the network device to update the first feature (Fl) and which occurred most recent within the first group (300B); merging (808) the configuration update events for the first feature (Fl) from the first feature creation time (T16) to the first feature to-time (T19), to create a toConfig merged feature update configuration; merging (810) the configuration update events for the first feature (Fl) from the first feature creation time (T16) to the first feature from-time (T24), to create a fromConfig merged feature update configuration; and performing (812) the generating (608) of the revert configuration state operation based on a difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration.

4. The method of Claim 3, wherein the performing (812) of the generating of the revert configuration state operation based on the difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration, is configured to revert configuration state of the first feature (Fl) in the network device from a configuration state of the first feature (Fl) in the network device at the from-time (T24) to a configuration state of the first feature (Fl) in the network device at the to-time (T19).

5. The method of any of Claims 1 to 4, further comprising: defining (900) a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature (F2) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300B) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2); defining (902) a third group (304) of configuration update events for the first feature (Fl) based on the information in the repository indicating the configuration update events for the first feature (Fl) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the second group (302) and without an intervening update event having been performed on any of the features of the network device other than the first feature (Fl); identifying (904) a second feature creation time when a most recent create operation was sent to the network device to create the second feature (F2) and which occurred next most recent prior to the third group (304); identifying (906) a second feature to-time (T15) when a most recent update operation was sent to the network device to update the second feature (F2) and which occurred next most recent prior to the third group (304); identifying (908) a second feature from -time (T21) when a most recent update operation was sent to the network device to update the second feature (F2) and which occurred most recent within the second group (302); merging (910) the configuration update events for the second feature (F2) from the second feature creation time to the second feature to-time (T15), to create a toConfig merged feature update configuration; merging (912) the configuration update events for the second feature (F2) from the second feature creation time to the second feature from-time (T21), to create a fromConfig merged feature update configuration; generating (914) a revert configuration state operation for the second feature (F2) based on a difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration; and following the sending (610) of the revert configuration state operation for the first group (300B) to the network device, sending (916) the revert configuration state operation for the second feature (F2) to the network device.

6. The method of Claim 5, further comprising: following the sending (916) of the revert configuration state operation for the second feature (F2) to the network device, and responsive to determining the first feature (Fl) had an existing state in the network device while the second group of configuration update events for the second feature (F2) were performed on the network device and further had a deleted state in the network device before the second group, generating a revert configuration state first feature delete operation to cause the network device to delete the first feature (Fl), and sending the revert configuration state first feature delete operation to the network device.

7. The method of any of Claims 1 to 6, wherein: the first group of configuration update events comprise a plurality of create feature, update feature, and/or delete feature operations; and the second group of configuration update events comprise a plurality of create feature, update feature, and/or delete feature operations. The method of any of Claims 1 to 7, wherein: the first feature (Fl) comprises one of a border gateway protocol, BGP, or an Ethernetlnterface by the network device; the second feature (F2) comprises the other of the border gateway protocol, BGP, or the Ethernetlnterface by the network device. The method of any of Claims 7 and 8, wherein: the first group (300B) of configuration update events comprise at least two update feature operations identifying at least a first neighbor Internet protocol, IP, address and a second neighbor IP address the network device is to add to a first neighbor table used by a first communication protocol; and the merging (606) of the first group (300B) of the configuration update events for the first feature into the merged configuration update event for the first group (300B) comprises generating the merged configuration update event for the first group to identify the at least first and second neighbor IP addresses the network device is to add to the first neighbor table used by the first communication protocol. The method of Claim 9, further comprising: defining (900) a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature (F2) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300B) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2), wherein the second group (302) of configuration update events comprise at least two update feature operations identifying at least a third neighbor IP address and a fourth neighbor IP address the network device is to add to a second neighbor table used by a second communication protocol which is different than the first communication protocol; merging (902) the second group (302) of the configuration update events for the second feature (F2) into a merged configuration update event for the second group (302) that identifies the at least third and fourth neighbor IP addresses the network device is to add to the second neighbor table used by the second communication protocol; generating (904) a revert configuration state operation for the second group (302) which is configured to revert the configuration state of the second feature (F2) based on the merged configuration update event for the second group (302); and following the sending (610) of the revert configuration state operation for the first group (300B) to the network device, sending (906) the revert configuration state operation for the second group (302) to the network device.

11. A computer program product comprising: a non-transitory computer readable medium storing instructions configured to be executed by at least one processor of a network management system (200) to cause the at least one processor to perform the method of any of Claims 1 to 10.

12. A network management system (200) for managing configuration states of features of network devices, the network management system (200) comprising: at least one processor (500); and at least one memory (510) coupled to the at least one processor (500) and storing computer readable program code that when executed by the at least one processor (500) causes the at least one processor (500) to perform operations configured to: maintain information in a repository (514) indicating configuration change events performed on the features of the network devices, the features comprising first (Fl) and second (F2) features; and respond to determination (602) a revert event being triggered to revert configuration states of the first and second features of a network device to a defined revert time (Tx), by operations to: define a first group (300 A, 300B) of configuration update events for the first feature (Fl) based on the information in the repository indicating the configuration update events for the first feature satisfy a rule for having been most recently sent the network device and for having been sequentially performed on the network device without an intervening update event having been performed on any of the features of the network device other than the first feature (Fl); merge the first group (300 A, 300B) of the configuration update events for the first feature into a merged configuration update event for the first group (300 A, 300B); generate a revert configuration state operation for the first group (300 A, 300B) which is configured to revert the configuration state of the first feature based on the merged configuration update event for the first group; and send the revert configuration state operation for the first group (300 A, 300B) to the network device.

13. The network management system (200) of Claim 12, the operations further comprising to: define a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300 A) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2); and responsive to determining the first feature (Fl) currently has a deleted state (T24) in the network device and had a prior existing state in the network device at a time next most recent prior (T19) to the second group (302), perform the merge of the first group (300 A) of the configuration update events for the first feature (Fl) into the merged configuration update event for the first group (300 A), perform the generation of the revert configuration state operation for the first group as a create first feature (Fl) operation to cause the network device to create the first feature based on the merged configuration update event for the first group (300 A), and perform the sending of the revert configuration state operation for the first group (300 A) to the network device.

14. The network management system (200) of any of Claims 12 to 13, the operations further comprising to: define a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature (F2) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300B) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2); identify a first feature (Fl) creation time (T16) when a most recent create operation was sent to the network device to create the first feature (Fl) and which occurred next most recent prior to the second group (302); identify a first feature to-time (T19) when a most recent update operation was sent to the network device to update the first feature (Fl) and which occurred next most recent prior to the second group (302); identify a first feature from-time (T24) when a most recent update operation was sent to the network device to update the first feature (Fl) and which occurred most recent within the first group (300B); merge the configuration update events for the first feature (Fl) from the first feature creation time (T16) to the first feature to-time (T19), to create a toConfig merged feature update configuration; merge the configuration update events for the first feature (Fl) from the first feature creation time (T16) to the first feature from-time (T24), to create a fromConfig merged feature update configuration; and perform the generation of the revert configuration state operation based on a difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration.

15. The network management system (200) of Claim 14, wherein the operation to perform the generating of the revert configuration state operation based on the difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration, is configured to revert configuration state of the first feature (Fl) in the network device from a configuration state of the first feature (Fl) in the network device at the from-time (T24) to a configuration state of the first feature (Fl) in the network device at the to-time (T19).

16. The network management system (200) of any of Claims 12 to 15, the operations further comprising to: define a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature (F2) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300B) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2); define a third group (304) of configuration update events for the first feature (Fl) based on the information in the repository indicating the configuration update events for the first feature (Fl) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the second group (302) and without an intervening update event having been performed on any of the features of the network device other than the first feature (Fl); identify a second feature creation time when a most recent create operation was sent to the network device to create the second feature (F2) and which occurred next most recent prior to the third group (304); identify a second feature to-time (T15) when a most recent update operation was sent to the network device to update the second feature (F2) and which occurred next most recent prior to the third group (304); identify a second feature from-time (T21) when a most recent update operation was sent to the network device to update the second feature (F2) and which occurred most recent within the second group (302); merge the configuration update events for the second feature (F2) from the second feature creation time to the second feature to-time (T15), to create a toConfig merged feature update configuration; merge the configuration update events for the second feature (F2) from the second feature creation time to the second feature from-time (T21), to create a fromConfig merged feature update configuration; generate a revert configuration state operation for the second feature (F2) based on a difference between the toConfig merged feature update configuration and the fromConfig merged feature update configuration; and following the sending of the revert configuration state operation for the first group (300B) to the network device, send the revert configuration state operation for the second feature (F2) to the network device.

17. The network management system (200) of Claim 16, the operations further comprising to: following the sending of the revert configuration state operation for the second group to the network device, and responsive to determining the first feature (Fl) had an existing state in the network device while the second group of configuration update events for the second feature (F2) were performed on the network device and further had a deleted state in the network device before the second group, generate a revert configuration state first feature delete operation to cause the network device to delete the first feature (Fl), and send the revert configuration state first feature delete operation to the network device.

18. The network management system (200) of any of Claims 12 to 17, wherein: the first group (300B) of configuration update events comprise a plurality of create feature, update feature, and/or delete feature operations; and the second group (302) of configuration update events comprise a plurality of create feature, update feature, and/or delete feature operations.

19. The network management system (200) of any of Claims 12 to 18, wherein: the first feature (Fl) comprises one of a border gateway protocol, BGP, or an

Ethernetlnterface by the network device; the second feature (F2) comprises the other of the border gateway protocol, BGP, or the Ethernetlnterface by the network device.

20. The network management system (200) of any of Claims 18 and 19, wherein: the first group (300B) of configuration update events comprise at least two update feature operations identifying at least a first neighbor Internet protocol, IP, address and a second neighbor IP address the network device is to add to a first neighbor table used by a first communication protocol; and the merging (606) of the first group (300B) of the configuration update events for the first feature into the merged configuration update event for the first group (300B) comprises generating the merged configuration update event for the first group to identify the at least first and second neighbor IP addresses the network device is to add to the first neighbor table used by the first communication protocol. The network management system (200) of Claim 20, wherein the operations further comprise to: define a second group (302) of configuration update events for the second feature (F2) based on the information in the repository indicating the configuration update events for the second feature (F2) satisfy a rule for having been sequentially performed on the network device and occurred next most recent prior to the first group (300B) and without an intervening update event having been performed on any of the features of the network device other than the second feature (F2), wherein the second group (302) of configuration update events comprise at least two update feature operations identifying at least a third neighbor IP address and a fourth neighbor IP address the network device is to add to a second neighbor table used by a second communication protocol which is different than the first communication protocol; merge the second group (302) of the configuration update events for the second feature (F2) into a merged configuration update event for the second group (302) that identifies the at least third and fourth neighbor IP addresses the network device is to add to the second neighbor table used by the second communication protocol; generate a revert configuration state operation for the second group (302) which is configured to revert the configuration state of the second feature (F2) based on the merged configuration update event for the second group (302); and following the sending of the revert configuration state operation for the first group (300B) to the network device, send the revert configuration state operation for the second group (302) to the network device.