Model-driven intent policy conflict detection and solution through graph analysis

Abstract

A method includes maintaining, by a controller device managing a plurality of network devices, a data structure, and receiving, by the controller device, an indication of a status intent. The method further includes generating, by the controller device, a logical packet based on the stateful intent, and determining, by the controller device, a dependency intent of the data structure based on the logical packet. The method also includes determining that the dependent intent conflicts with the stateful intent. The method further includes, in response to determining that the dependency intent conflicts with the stateful intent, determining, by the controller device, a solution to resolve the conflict between the dependency intent and the stateful intent based on the dependency intent and the stateful intent, and outputting, by the controller device, an indication of the solution.

Description

[0001] This divisional application is a divisional application of the Chinese invention patent application with application number 202110037602.4, application date January 12, 2021, and priority date October 21, 2020. Technical Field

[0002] The present disclosure relates to computer networks, and more particularly to management of network devices. Background Art

[0003] Network devices typically include mechanisms for configuring the device locally or remotely, such as a management interface. By interacting with the management interface, the client can perform configuration tasks and execute operational commands to collect and view operational data of the managed device. For example, the client can configure the interface card of the device, adjust the parameters of the supported network protocols, specify the physical components within the device, modify the routing information maintained by the router, access software modules and other resources resident on the device, and perform other configuration tasks. In addition, the client can allow the user to view current operating parameters, system logs, information related to network connections, network activity or other status information from the device, and view and respond to event information received from the device.

[0004] Network configuration services can be performed by multiple different devices, such as routers with service cards and / or dedicated service devices. Such services include connection services, such as Layer 3 Virtual Private Network (L3VPN), Virtual Private LAN Service (VPLS), and Peer-to-Peer (P2P) services. Other services include network configuration services, such as Dot1q VLAN services. Network management systems (NMS) and NMS devices (also known as controllers or controller devices) can support these services, allowing administrators to easily create and manage these advanced network configuration services.

[0005] In particular, user configurations of devices can be referred to as "intents". Intent-based networking systems allow administrators to describe the expected network / compute / storage state. User intent can be categorized as business policy or stateless intent. Business policy or stateful intent can be resolved based on the current state of the network. Stateless intent can be a fully declarative way to describe the expected network / compute / storage state without paying attention to the current network state.

[0006] Intents can be represented as an intent data model that can be modeled using a unified graph. The intent data model can be represented as a connected graph so that business policies can be implemented across a business computing architecture. For example, the data model can be represented using a data structure that is, for example, a connected graph where vertices are connected by has-edges and ref-edges. A controller device can model the intent data model as a unified graph. In this way, business policies can be implemented across the intent data model. When intents are modeled using a unified graph model, extending new intent support can extend the graph model and compilation logic.

[0007] To configure a device to execute an intent, a user (such as an administrator) can write a conversion program that converts high-level configuration instructions (e.g., instructions that conform to an intent data model, which can be represented as a unified graph model) into low-level configuration instructions (e.g., instructions that conform to a device configuration model). As part of the configuration service support, the user / administrator can provide an intent data model and a mapping between the intent data model and the device configuration model.

[0008] In order to simplify the mapping definition for the user, the controller device can be designed to provide the ability to define mappings in a simple manner. For example, some controller devices provide the use of velocity templates and / or extensible stylesheet language transformations (XSLT). Such a converter may include conversion or mapping logic from a high-level intent data model to a low-level device configuration model. In some cases, a relatively small number of changes in the intent data model may affect a relatively large number of attributes across device configurations. Different converters can be used when creating, updating, and deleting services from the intent data model. Summary of the invention

[0009] In general, the present disclosure describes techniques for detecting conflicts between intents and providing solutions to the conflicts. For example, before a stateful intent is converted into a device-level configuration, a controller device may determine that a dependent intent of a data structure (e.g., a graph model) conflicts with the stateful intent. In this example, the controller device may determine a solution to resolve the conflict between the stateful intent and the dependent intent. In this way, the controller device may resolve conflicts at the intent level rather than in the device-level configuration, which may achieve improved scalability compared to systems that resolve conflicts at the device level.

[0010] The techniques described herein can allow a controller device to automatically perform validation to help ensure that there are no conflicts between different intents. For example, a controller device can identify conflicts and generate solutions that resolve the conflicts while potentially satisfying both the intent and the existing intent, rather than overwriting the existing intent with the intent.

[0011] In one example, the present disclosure describes a method comprising: maintaining, by a controller device that manages multiple network devices, a data structure comprising multiple vertices and multiple edges, each of the multiple vertices representing a corresponding network device among the multiple network devices or a corresponding stateless intent among multiple stateless intents, and the multiple edges defining a relationship between the multiple vertices; receiving, by the controller device, an indication of a stateful intent, the stateful intent specifying an expected state to be converted into one or more device-level configuration changes of the multiple network devices; generating, by the controller device, a logical grouping based on the stateful intent; determining, by the controller device, a dependency intent of the data structure based on the logical grouping; determining, by the controller device, a conflict between the dependency intent and the stateful intent; and in response to determining that the dependency intent conflicts with the stateful intent: determining, by the controller device, a solution to resolve the conflict between the dependency intent and the stateful intent based on the dependency intent and the stateful intent; and outputting, by the controller device, an indication of the solution.

[0012] In another example, the present disclosure describes a device that is configured to manage multiple network devices and: maintain a data structure including multiple vertices and multiple edges, each of the multiple vertices representing a corresponding network device in a plurality of network devices or a corresponding stateless intent in a plurality of stateless intents, and the multiple edges defining a relationship between the multiple vertices; receive an indication of a stateful intent, the stateful intent specifying an expected state to be converted to one or more device-level configuration changes for the multiple network devices; generate logical groupings based on the stateful intent; determine a dependent intent of the data structure based on the logical groupings; determine that the dependent intent conflicts with the stateful intent; and in response to determining that the dependent intent conflicts with the stateful intent: determine a solution to resolve the conflict between the dependent intent and the stateful intent based on the dependent intent and the stateful intent; and output an indication of the solution.

[0013] In one example, the present disclosure describes a computer-readable storage medium comprising one or more instructions that cause a processing circuit system to perform the following operations: maintaining a data structure comprising multiple vertices and multiple edges, each of the multiple vertices representing a corresponding network device among multiple network devices or a corresponding stateless intent among multiple stateless intents, and the multiple edges defining a relationship between the multiple vertices; receiving an indication of a stateful intent, the stateful intent specifying an expected state to be converted into one or more device-level configuration changes of the multiple network devices; generating logical groupings based on the stateful intent; determining a dependent intent of the data structure based on the logical groupings; determining that the dependent intent conflicts with the stateful intent; in response to determining that the dependent intent conflicts with the stateful intent: determining a solution to resolve the conflict between the dependent intent and the stateful intent based on the dependent intent and the stateful intent; and outputting an indication of the solution.

[0014] The details of one or more examples are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 is a block diagram illustrating an example of a network device including an enterprise network upgraded using a controller device in accordance with the techniques of this disclosure.

[0016] Figure 2 It is shown for Figure 1 A block diagram of an example set of components of a controller device.

[0017] Figure 3 is a conceptual diagram illustrating an example unified graph model for an intent data model.

[0018] Figure 4 is a conceptual diagram illustrating an example controller device configured to generate device-level configurations using intents in accordance with techniques of this disclosure.

[0019] Figure 5 is a conceptual diagram illustrating an example data structure according to techniques of this disclosure.

[0020] Figure 6 is a conceptual diagram illustrating an example controller device configured to perform conflict detection using graph-based stateful intent analysis in accordance with techniques of this disclosure.

[0021] Figure 7 is a conceptual diagram illustrating a first example of intentional ordering of child source nodes and parent source nodes according to the technology of the present disclosure.

[0022] Figure 8 is a conceptual diagram illustrating a second example of the intended ordering of child source nodes and parent source nodes according to the technology of the present disclosure.

[0023] Fig. 9 is a conceptual diagram illustrating an example of intent ordering of site-specific source nodes and global nodes according to techniques of this disclosure.

[0024] Fig.10 is a conceptual diagram illustrating an example of redundant intention detection according to the technology of the present disclosure.

[0025] Fig.11 is a conceptual diagram illustrating an example of redundant intent parsing according to the technology of the present disclosure.

[0026] Fig.12 is a flow chart illustrating an example process for determining a resolution to a conflict of intent in accordance with the techniques of this disclosure.

[0027] Like reference numerals refer to like elements throughout the drawings and description. DETAILED DESCRIPTION

[0028] The present disclosure relates to a controller device that supports intent-based workflows to manage a network. As used herein, an intent may refer to a fully declarative way of describing an expected network / compute / storage state. For example, a user (e.g., an administrator) may write a conversion program that converts high-level configuration instructions (e.g., instructions that conform to an intent data model, which may be represented as a unified graph model) into low-level configuration instructions (e.g., instructions that conform to a device configuration model) that may be applied to resources of a network. As used herein, a unified model graph or "unified intent graph" may refer to a graph that includes stateless intents as vertices and endpoints as vertices (also referred to herein as "nodes"). As part of configuration service support, a user / administrator may provide an intent data model and a mapping between the intent data model and a device configuration model.

[0029] Certain systems (e.g., network security management systems) may support rule analysis that can detect shadow rules, redundant rules, and / or rule placement by analyzing device-level rules. In contrast, the techniques described herein may operate in a stateful intent layer with high-level objects. In this way, the techniques described herein that operate in a stateful intent layer may perform intent-level analysis to determine conflicts that may not be inferred from device-level rules. In addition, the techniques described herein that operate in a stateful intent layer may provide improved scalability compared to systems that rely on device-level rules.

[0030] The techniques described herein that operate in a stateful intent layer can have improved performance compared to systems that rely on device-level rules. For example, the techniques described herein that operate in a stateful intent layer can use graph analysis that enables eager graph synthesis by modeling a hierarchical structure of endpoints and representing intent actions as edges. As used herein, eager synthesis can include processes for detecting intent conflicts in real time. Using graph analysis (such as eager synthesis) can help keep the performance of conflict resolution constant, rather than increasing linearly with the number of rules in the system. For example, in security management, the number of rules can be thousands, which may not scale well for systems that rely on device-level rules.

[0031] Compared to systems that rely on device-level rules, the techniques described herein that operate in a stateful intent layer can have improved intent recovery. For example, when intents have conflicts, the techniques described herein that operate in a stateful intent layer can implement a conversational interface with various recovery options. Compared to systems that rely on device-level rules, the techniques described herein that operate in a stateful intent layer can have improved scalability. For example, the techniques described herein that operate in a stateful intent layer can provide a model-based (e.g., a unified graph model) solution that can help achieve scalability of new intent models registered in the system.

[0032] The present disclosure describes a model-driven approach for one or more of the following. In some examples, the techniques described herein may configure a controller device to detect intent policy conflicts on the same intent type in real time. Examples of intent types (also referred to herein as "actions") may include, for example, a connection type, a firewall type (e.g., allow, block), a network address translation (NAT) type, or another intent type. For example, a controller device may be configured to detect and resolve conflicting security intents. For example, a first intent may include a firewall allow type that allows a marketing group to communicate with a salesperson application. In this example, a second intent may include a firewall allow type that denies all groups (including the marketing group) from communicating with the Internet. The techniques described herein that operate in a stateful intent layer may detect a conflict between a first intent and a second intent and resolve the conflict.

[0033] The techniques described herein can configure a controller device to detect intent policy conflicts across different intent types in real time. For example, a first intent can include a firewall intent to allow a first address (e.g., Address1") to access a sales application. In this example, a second intent can include a NAT of the first address to a second address (e.g., Address2). In this example, the second intent (e.g., NAT of the first address to the second address) will override the firewall intent of the first intent ("allow"). The techniques described herein operating in a stateful intent layer can detect conflicts between a first intent and a second intent and resolve the conflict.

[0034] The techniques described herein may configure a controller device to provide a solution when a conflict is observed. The solution may include changing the order of intents in the case of firewall intents. For example, a controller device may apply a NAT type before applying a firewall allow type or a firewall deny type (also referred to herein as a "firewall block type"). In some examples, in order to provide a solution when a conflict is observed, a controller device may modify the intent. For example, a controller device may modify a first intent that denies all groups (including the marketing group) from communicating with the Internet to allow the marketing group to communicate with the Internet to satisfy a second intent that allows the marketing group to communicate with sales personnel using the Internet.

[0035] The technology described herein can configure the controller device to verify intent when a direct policy change or an out-of-band (OOB) change occurs. For example, a user (e.g., an administrator) may modify a policy directly. In this example, the controller device can verify the business policy against these changes and provide the affected business policy.

[0036] The techniques described herein may configure a controller device to verify intent when discovered from a Brownfield deployment (e.g., when a previously established network device is connected to the controller device). When verifying intent at discovery, the intent may be "shadowed" because device rules are misplaced or the intent may be invalid. As used herein, for example, a first intent including the change to be applied to a subgroup is shadowed when a second intent applies a change to a group that includes a subgroup. In this case, the first intent is shadowed such that the second intent makes the first intent redundant. For example, a first intent may allow a marketing group to communicate with the Internet, and a second intent may allow all groups including the marketing group to communicate with the Internet.

[0037] The techniques described herein can configure the controller device to be extensible to allow new intent types. For example, the controller device can include other types besides connection type, firewall type (e.g., allow, block), and network address translation (NAT) type.

[0038] According to the technology of the present disclosure, a controller device can be configured to apply extensions to a policy graph abstraction (PGA) to model intent dependencies, detect conflicts in intents (e.g., firewall intents), and provide solutions through the ordering of intents (e.g., firewall intents). The present disclosure also provides a method for a stateful intent layer for heterogeneous intent types, which can help allow a controller device to detect conflicts on any intent, provide solutions to intent conflicts, discover business policies from Brownfield deployments (e.g., deploy previously configured devices), and / or verify intents.

[0039] According to the technology of the present disclosure, when a new intent is created or updated, the controller device can form a logical grouping based on the intent. For example, the controller device can receive the intent "NAT intent: NAT Address1 to Address2". In this example, the controller device can form a logical grouping "{Action: IP Translate, Src: Address2}" based on the intent. The controller device can apply a transformation function that produces an updated logical grouping "{Action: IP Translate, Src: Address2, properties: {OldSrc: Address1}}".

[0040] Based on the intent dependencies of the data structure (e.g., unified graph model), a stateful intent analysis engine (also referred to herein as "intent analysis engine") of the controller device can select one or more dependent intents. Analysis handlers of the controller device can be registered for intents. For example, a "function nat intent analysis" function can be configured for NAT intent, and a "function firewall intent analysis" function can be configured for firewall intent.

[0041] The intent analysis engine can work with the analysis handler to check whether the intent change conflicts with any dependent intent in one or more dependent intents. If the intent change conflicts with any dependent intent in one or more dependent intents, the intent analysis engine will provide a solution together with the analysis handler. The solution may be to sort the modified intent or change the current intent. The intent analysis engine can attach any changes (for example, sorting the modified intent or changing the current intent) to the group as a "ChangeList". For example, the intent analysis engine can attach "{Action:IPTranslate,Src:Address2,properties:{OldSrc:Address1,ChangeList:[Intent type:FirewallIntent,uuid:1234,changes]}}" to the change list. In this way, the intent analysis engine can help ensure a conflict-free synthesis strategy. As used in this article, a conflict-free synthesis strategy may refer to a strategy without any conflicts.

[0042] Figure 11 is a block diagram showing an example of network devices including an enterprise network 2 managed using a controller device 10. The network devices 14A-14G (collectively referred to as "network devices 14") of the enterprise network 2 include network devices that are interconnected via communication links to form a communication topology to exchange resources and information. The network devices 14 (also commonly referred to as remote network devices) may include, for example, routers, switches, gateways, bridges, hubs, servers, firewalls or other intrusion detection systems (IDS) or intrusion prevention systems (IDP), computing devices, computing terminals, printers, other network devices, or combinations of such devices. Although described in this disclosure as transmitting, conveying, or otherwise supporting packets, the enterprise network 2 may transmit data according to any other discrete data unit defined by any other protocol, such as a cell defined by an asynchronous transfer mode (ATM) protocol, or a datagram defined by a user datagram protocol (UDP). The communication links interconnecting the network devices 14 may be physical links (e.g., optical, copper, etc.), wireless links, or any combination thereof.

[0043] Enterprise network 2 is shown coupled to public network 18 (e.g., the Internet) via a communication link. Public network 18 may include, for example, one or more client computing devices. Public network 18 may provide access to network servers, application servers, public databases, media servers, end-user devices, and other types of network resource devices and content.

[0044] The controller device 10 is communicatively coupled to the network device 14 via the enterprise network 2. In some examples, the controller device 10 forms part of a device management system, however, for Figure 1For the purpose of example, only one device of the device management system is shown. The controller device 10 can be directly or indirectly coupled to various network devices 14. Once the network devices 14 are deployed and activated, the administrator 12 uses the controller device 10 (or multiple such management devices) to manage the network devices using a device management protocol. An example device protocol is the Simple Network Management Protocol (SNMP), which allows the controller device 10 to traverse and modify the management information base (MIB) storing configuration data in each managed network device 14. Another example device protocol may include NETCONF, however, the techniques described herein may be used with other device protocols. More details of the SNMP protocol can be found in "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks" (Harrington et al., Internet Engineering Task Force Draft of the Network Working Group, RFC 3411, December 2002) (available from http: / / tools.ietf.org / html / rfc3411), the entire contents of which are incorporated herein by reference. Another example device protocol may include NETCONF, however, the techniques described herein may be used with other device protocols. More details of the NETCONF protocol may be found in “Network Configuration Protocol (NETCONF)” (Enns et al., Internet Engineering Task Force Draft of the Network Working Group, RFC 6241, June 2011) (available from http: / / tools.ietf.org / html / rfc6241), the entire contents of which are incorporated herein by reference.

[0045] In common practice, the controller device 10 (also referred to as a network management system (NMS) or NMS device) and the network devices 14 are centrally maintained by the enterprise's IT department. The administrator 12 interacts with the controller device 10 to remotely monitor and configure the network devices 14. For example, the administrator 12 can receive alerts about any network device 14 from the controller device 10, view the configuration data of the network device 14, modify the configuration data of the network device 14, add new network devices to the enterprise network 2, delete existing network devices from the enterprise network 2, or otherwise manipulate the enterprise network 2 and the network devices therein. Although described with respect to an enterprise network, the technology of the present disclosure is applicable to other network types (public and private), including LANs, VLANs, VPNs, etc.

[0046] In some examples, the administrator 12 uses the controller device 10 or a local workstation to interact directly with the network device 14, for example, via telnet, secure shell (SSH), or other such communication sessions. That is, the network device 14 typically provides an interface for direct interaction, such as a command line interface (CLI), a network-based interface, a graphical user interface (GUI), etc., through which a user can interact with the device to directly issue text-based commands. For example, these interfaces typically allow a user to interact directly with the device, such as via telnet, secure shell (SSH), hypertext transfer protocol (HTTP), or other network sessions, to enter text according to a defined syntax to submit commands to the managed element. In some examples, a user uses the controller device 10 to initiate an SSH session 15 with one of the network devices 14 (e.g., network device 14F) to directly configure the network device 14F. In this way, a user can provide commands in an execution format directly to the network device 14.

[0047] In addition, the administrator 12 may also create scripts that may be submitted by the controller device 10 to any or all of the network devices 14. For example, in addition to the CLI interface, the network device 14 may also provide an interface for receiving scripts that specify commands according to a scripting language. In a sense, the script may be output by the controller device 10 to automatically invoke a corresponding remote procedure call (RPC) on the managed network device 14. The script may conform to, for example, the Extensible Markup Language (XML) or another data description language.

[0048] The administrator 12 uses the controller device 10 to configure the network device 14 to specify certain operational characteristics to further achieve the goals of the administrator 12. For example, the administrator 12 can specify specific operational policies for the network device 14 regarding security, device accessibility, traffic engineering, quality of service (QoS), network address translation (NAT), packet filtering, packet forwarding, rate limiting, or other policies. The controller device 10 uses one or more network management protocols designed for managing configuration data within the network device 14 (such as the SNMP protocol or the Network Configuration Protocol (NETCONF) protocol or its derivatives, such as the Juniper Device Management Interface) to perform configuration. In general, NETCONF provides a mechanism for configuring network devices and uses data encoding based on the Extensible Markup Language (XML) for configuration data, where the configuration data may include policy data. NETCONF is described in "NETCONF Configuration Protocol" (Enns, Network Working Group, RFC 4741, December 2006) (available from tools.ietf.org / html / rfc4741). The controller device 10 can establish a NETCONF session with one or more network devices 14.

[0049] The controller device 10 may be configured to compare the new intent data model with the existing (or old) intent data model, determine differences between the new intent data model and the existing intent data model, and apply a reactive mapper to the differences between the new intent data model and the old intent data model. In particular, the controller device 10 determines whether the new configuration data set includes any additional configuration parameters relative to the old intent data model, and whether the new configuration data set modifies or omits any configuration parameters included in the old intent data model.

[0050] The intent data model can be a unified graph model, and the low-level configuration data can be represented in YANG, which is described in Bjorklund's "YANG—A Data Modeling Language for the Network Configuration Protocol (NETCONF)" in RFC 6020 of the Internet Engineering Task Force, October 2010 (available from tools.ietf.org / html / rfc6020). In some examples, the intent data model can be represented in YAML Ain't Markup Language (YAML). The controller device 10 may include various reactive mappers for converting intent data model differences. These functions are configured to accept the intent data model (which can be represented as a structured input parameter, for example, in accordance with YANG or YAML). The functions are also configured to output a corresponding low-level device configuration data change set, such as the addition and deletion of device configurations. That is,

[0051] y1=f1(x),y2=f2(x),...y N =f N (X).

[0052] The controller device 10 may use the YANG model for an intent data model and a low-level device configuration model. The data may contain relationships across YANG entities, such as list items and containers. Traditionally, controller devices cannot support configuration management functions in real time. As discussed in more detail below, the controller device 10 may convert a YANG data model into a database model and convert YANG validation into data validation. Technology for managing network devices using a graph model for high-level configuration data is described in U.S. patent application No. 15 / 462,465, entitled “CONFIGURING AND MANAGING NETWORK DEVICES USING PROGRAM OVERLAY ON YANG-BASED GRAPH DATABASE,” filed on March 17, 2017, the entire contents of which are incorporated herein by reference.

[0053] The controller device 10 may receive data representing any or all of create, update and / or delete actions with respect to the unified intent data model from one of the administrators 12. The controller device 10 may be configured to use the same compilation logic for each of create, update and delete actions applied to the graph model.

[0054] Typically, controllers similar to the controller device 10 use a hierarchical data model for intents, low-level data models, and resources. The hierarchical data model can be based on YANG or YAML. As described above, the hierarchical data model can be represented as a graph. Modern systems already support intents to simplify network management. Intents are declarative. To implement the intent, the controller device 10 tries to select the best resources.

[0055] According to the technology of the present disclosure, the controller device can maintain a data structure. The data structure can include multiple vertices and multiple edges, each vertex in the multiple vertices represents a corresponding network device in the network device 14 or a corresponding stateless intent in the multiple stateless intents, and the multiple edges define the relationship between the multiple vertices.

[0056] The controller device 10 may be configured to receive an indication of a stateful intent. In some examples, the stateful intent specifies an expected state to be converted into one or more device-level configuration changes for the network device 14. The controller device 10 may generate logical groupings based on the stateful intent. For example, the controller device 10 may apply an intent policy function (e.g., a function firewall intent policy or a function nat-intent policy) that generates logical groupings based on the intent.

[0057] The controller device 10 may determine the dependent intent of the data structure based on the logical grouping. For example, the controller device 10 may determine the intent type based on the intent. In this example, the controller device 10 may traverse the logical grouping from the source indicated by the intent to the destination indicated by the intent to determine one or more edges (e.g., vertices representing intended actions) having an intent type determined based on the intent. The controller device 10 may determine the dependent intent as the intent specified by one or more edges having an intent type determined based on the intent. For example, the controller device 10 may determine that the intent to convert a network address from a first address to a second address specifies a "firewall allow" dependent type. In this case, the controller device 10 may determine the intent of the ancestor edge having the firewall allow intent type as the dependent intent.

[0058] The controller device 10 may determine whether a dependent intent conflicts with a stateful intent. In response to determining that the dependent intent conflicts with the stateful intent, the controller device 10 may determine a solution to resolve the conflict between the dependent intent and the stateful intent based on the dependent intent and the stateful intent. For example, the controller device 10 may determine a solution by reordering the intent so that the controller device 10 converts the network address from a first address to a second address and then applies the firewall-allowed intent to the second address. Determining whether intents in a stateful intent layer conflict may improve the performance of detecting conflicts between intents compared to a system that relies on device-level rules. The controller device 10 may output an indication of a solution. For example, the controller device 10 may attach a list of changes to a logical grouping.

[0059] Figure 2 It is shown for Figure 1 1 is a block diagram of an example set of components of a controller device 10. In this example, the controller device 10 includes a control unit 22, a network interface 34, and a user interface 36. The network interface 34 represents a device that can communicatively couple the controller device 10 to an external device (e.g., Figure 1 The network interface 34 may represent a wireless and / or wired interface, such as an Ethernet interface or a radio configured to communicate according to a wireless standard such as one or more IEEE 802.11 wireless networking protocols such as 802.11a / b / g / n or other such wireless protocols. In various examples, the controller device 10 may include multiple network interfaces, but only one network interface is shown for example for purposes of illustration.

[0060] The control unit 22 represents any combination of hardware, software and / or firmware for implementing the functions attributed to the control unit 22 and its component modules and elements. When the control unit 22 includes software or firmware, the control unit 22 also includes any necessary hardware for storing and executing the software or firmware, such as one or more processors or processing units. Typically, the processing unit may include one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuit systems, and any combination of such components. In addition, the processing unit is typically implemented using fixed and / or programmable logic circuit systems.

[0061] The user interface 36 represents one or more interfaces, such as the administrator 12 ( Figure 1 ) interacts with the controller device 10 through the one or more interfaces, for example, to provide input and receive output. For example, the user interface 36 may represent one or more of a display, a keyboard, a mouse, a touch screen, a touch pad, a trackpad, a speaker, a camera, a microphone, etc. In addition, although the controller device 10 includes a user interface in this example, the administrator 12 need not interact directly with the controller device 10, but may access the controller device 10 remotely, for example, via the network interface 34.

[0062] The control unit 22 includes a user interface module 38, a network interface module 32, and a management module 24. The control unit 22 executes the user interface module 38 to receive input from the user interface 36 and / or provide output to the user interface 36. The control unit 22 also executes the network interface module 32 to send and receive data (e.g., packets) via the network interface 34. The user interface module 38, the network interface module 32, and the management module 24 may again be implemented as respective hardware units, or in the form of software or firmware or a combination thereof.

[0063] The functionality of the control unit 22 may be implemented as one or more processing units in a fixed or programmable digital logic circuit system. Such digital logic circuit systems may include one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuit systems, and any combination of such components. When implemented as a programmable logic circuit system, the control unit 22 may also include one or more computer-readable storage media storing hardware or firmware instructions to be executed by the (multiple) processing units of the control unit 22.

[0064] The control unit 22 executes the management module 24 to manage various network devices, such as Figure 1 The management of network devices includes, for example, Figure 1 The management module 24 may further include an analysis processing program 27 and a conversion module 28.

[0065] The management module 24 is configured to receive configuration data for the intent unified graph modeling of a set of managed network devices from a user (such as an administrator 12). Such configuration data for the intent unified graph modeling can be referred to as an "intent data model". The user can update the configuration data over time, for example to add new services, delete existing services, or modify existing services performed by managed devices. The unified intent data model can be constructed according to, for example, YANG or YAML. The graph model may include multiple vertices connected in a hierarchical manner by edges. In YANG, the edges of the graph model are represented by "leafref" elements. In the case of YAML, such edges can be represented by "reference (ref)" edges. Similarly, parent-child vertex relationships can be represented by "has" edges. For example, the vertex of element A uses has-edge to reference the vertex of element B, which can be understood as indicating "element A has element B". In some examples, the management module 24 also provides the user with the ability to submit a reactive mapper, which is executed by the conversion module 28 to convert the intent data model into device-specific low-level configuration instructions.

[0066] The controller device 10 also includes a configuration database 40. The configuration database 40 may include a data structure describing a managed network device (e.g., network device 14). The configuration database 40 may be used as an intent data repository, which may be used to persist and manage a collection of intent data models. For example, the configuration database 40 may include information indicating a device identifier (such as a MAC and / or IP address), a device type, a device vendor, a device type (e.g., a router, a switch, a bridge, a hub, etc.), etc. The configuration database 40 also stores current configuration information (e.g., an intent data model, or in some cases, both an intent data model and low-level configuration information) of a managed device (e.g., network device 14). The configuration database 40 may include a database including a unified intent data model. In some examples, the configuration database 40 may store a low-level configuration, which includes a pointer to the owner of the corresponding owned resource of the network device 14 for each corresponding owned resource in a set of owned resources.

[0067] According to the technology of the present disclosure, the management module 24 can maintain a data structure in the configuration database 40. The data structure may include a plurality of vertices and a plurality of edges, each vertex in the plurality of vertices representing a corresponding network device (e.g., network device 14) in a plurality of network devices or a corresponding stateless intent in a plurality of stateless intents, and the plurality of edges defining a relationship between the plurality of vertices. The management module 24 can receive an indication of a stateful intent. For example, the management module 24 can receive configuration data modeled as a unified graph of intents for a set of managed network devices from a user such as the administrator 12.

[0068] Management module 24 can generate logical groupings based on stateful intent. For example, management module 24 can apply an intent policy function (e.g., a function firewall intent policy or a function nat-intent policy) that generates logical groupings based on the intent generated by user interface module 38.

[0069] The analysis handler 27 may be configured to determine dependent intents of a data structure based on a logical grouping. For example, the analysis handler 27 may determine an intent type based on an intent. In this example, the analysis handler 27 may traverse the logical grouping from a source indicated by the intent to a destination indicated by the intent to determine one or more edges (e.g., vertices representing intended actions) having an intent type determined based on the intent. The analysis handler 27 may determine the dependent intent as an intent specified by one or more edges having an intent type determined based on the intent. For example, the analysis handler 27 may determine that an intent to convert a network address from a first address to a second address specifies "firewall allow" as a dependent type. In this case, the analysis handler 27 may determine the intent having an ancestor edge of the firewall allow intent type as the dependent intent.

[0070] Analysis handler 27 may determine whether a dependent intent conflicts with a stateful intent. In response to determining that a dependent intent conflicts with a stateful intent, analysis handler 27 may determine a solution to resolve the conflict between the dependent intent and the stateful intent based on the dependent intent and the stateful intent. For example, analysis handler 27 may determine a solution to reorder the intent so that management module 24 converts a network address from a first address to a second address and then applies the firewall-allowed intent to the second address. Determining whether intents in a stateful intent layer conflict may improve the performance of detecting conflicts between intents compared to systems that rely on device-level rules. Analysis handler 27 may output an indication of a solution. For example, analysis handler 27 may attach a list of changes to a logical grouping.

[0071] Although for exemplary purposes the user interface 36 is described as allowing the administrator 12 ( Figure 1) to interact with controller device 10, but other interfaces may be used in other examples. For example, controller device 10 may include a representational state transfer (REST) ​​client (not shown) that may be used as an interface with another device, through which administrator 12 may configure controller device 10. Similarly, administrator 12 may configure network device 14 by interacting with controller device 10 using a REST client.

[0072] Management module 24 may model configuration database 40 as a graph database representing YANG configuration data elements. YANG specifies various types of data structures, including lists, leaf lists, containers, containers with presence, and features. Management module 24 may model lists, containers, containers with presence, and features, as well as top-level containers, as vertices in a graph database. Alternatively, configuration database 40 may represent YAML configuration data elements.

[0073] After constructing the graph database, the management module 24 can perform operations on the data of the graph database. For example, the management module 24 can map Netconf-based operations (such as get-config, get-config with filters, and edit-config) to graph query language queries (such as Gremlin queries). Gremlin is described in GremlinDoc at gremlindocs.spmallette.documentup.com and github.com / tinkerpop / gremlin / wiki. If the conditional attributes change, the management module 24 can execute the conditions mapped to the vertices and edges of the graph database. In response to the conditions, the management module 24 can process additional changes, which are processed as functions, as discussed in more detail below. The management module 24 can also update all changes in transaction semantics.

[0074] Figure 3 is a conceptual diagram illustrating an example unified graph model 60 for an intent data model. Figure 3 The process shown may represent an example of how the controller device 10 may generate a configuration generated from an intent. The unified graph model 60 may be composed of Figure 2 4. In this example, the unified graph model 60 includes nodes A 62, B ​​64, C 66, etc., which can represent corresponding network devices (e.g., network device 14). As shown, the unified graph model 60 can include edges defining the relationship between multiple nodes A 62, B ​​64, and C 66. For example, the edge connecting node B 64 and node C 66 via LSP2 can define the RSVP LSP between node B 64 and node C 66.

[0075] Initially, unified graph model 60 may not include VPN 68, VPN 72, and VPN 78, nor optical 80, lambda 82, optical 84, and lambda 86. As a result of the modification through the intent data model update, node A 62 is coupled to node B 64 via VPN 68 and LSP1 70, node B 64 is coupled to node C 66 via VPN 72 and LSP2 74, and node C 66 is coupled to node A 62 via VPN 78 and LSP3 76. In addition, additional nodes optical 80, lambda 82, optical 84, and lambda 86 are added between node B 64 and node C 66 because additional capacity is required due to the optical intent.

[0076] Stateful business policies can be written on top of the stateless intent layer. For example, a user can declare the intent "provide high bandwidth VPN connections between sites A, B, and C, and provide bandwidth between AB, BC, CA, ... ". This can result in a variety of stateless intents. Stateful intents can be compiled into L3VPN (overlay tunnels) and a transport mechanism that provides the required bandwidth between AB, BC, CA. For example, the transport mechanism may include: 30Mbps RSVP LSP between AB, 50Mbps RSVP LSP between BC, and 80Mbps RSVP LSP between CA. In this case, it may be necessary to create an 80Mbps RSVP-LSP between CAs. There may be situations where more capacity is needed, so there may be a further intent "Optical intent: increase capacity between CAs". If a 70Mbps connection already exists between CAs, a stateless intent can provide a new 10G lambda between CAs on the optical network.

[0077] When implementing stateful intents, controller devices such as controller device 10 may need to consider existing stateless intents across endpoints as well as the current state. In the above example, in order to execute various intents, controller device 10 can query the connectivity graph (including stateless intents) and create / modify stateless intents when necessary. Technology related to the use of a unified graph model and intents is described in U.S. application Ser. No. 15 / 462,465, filed on March 17, 2017, the entire contents of which are incorporated herein by reference. Therefore, the intent data model can be represented using a unified graph model. When more use cases are added, the intent data model (i.e., the unified graph model) can be expanded. Moreover, the use of a unified graph model allows intents to be retrieved based on endpoints (e.g., by querying a graph).

[0078] However, even taking into account the existing stateless intent, a controller device (e.g., controller device 10) may apply a conflicting intent configuration template (configlet) so that the controller device no longer implements the stateful intent, which may result in the controller device being unable to maintain the configuration generated from the intent. For example, the controller device may receive a first intent that specifies a set of configuration changes to be applied to node B 64 and node C 66. For example, the controller device may receive a first intent that specifies a set of configuration changes to LSP2 74 that reduce the bandwidth from 50 Mbps to 30 Mbps. In this example, applying the first intent causes the controller device to no longer configure the network device 14 to implement a RSVP LSP of 50 Mbps between BC, which may result in the controller device being unable to meet a second intent for a specific bandwidth between node A 62 and node C 66.

[0079] According to the techniques described herein, the controller device 10 may be configured to determine whether a dependent intent (e.g., an existing intent) conflicts with a stateful intent applied to the unified graph model 60. In response to determining that the dependent intent conflicts with the stateful intent, the analysis handler 27 may determine a solution to resolve the conflict between the dependent intent and the stateful intent based on the dependent intent and the stateful intent. For example, the controller device 10 (e.g., the analysis handler 27) may determine the following solution: reorder the intents so that the management module 24 converts the network address from the first address to the second address and then applies the firewall-allowed intent to the second address. Determining whether intents in a stateful intent layer conflict can improve the performance of detecting conflicts between intents compared to systems that rely on device-level rules.

[0080] Figure 4 is a conceptual diagram illustrating an example controller device 210 configured to use intent to generate device-level configurations according to the techniques of this disclosure. The controller device 210 may be Figure 1 An example of a controller device 10.

[0081] The controller device 210 may represent an intent-based controller system. The controller device 210 may be configured to support intents to simplify the management of the network. The intent may be declarative. To implement the intent, the controller device 210 may select the best resource (e.g., a user network interface (UNI) in a connection service such as a software-driven (SD) wide area network (WAN), a virtual private network (VPN), or another resource). In terms of security, the controller device 210 may support firewall policies, NAT, unified threat management (UTM) through intent. The controller device 210 may use hierarchical data for intents, low-level device configuration models, and / or resources.

[0082] The controller device 210 may support security policies based on user intent. For example, the controller device 210 may create policies based on logical business structures such as, but not limited to, users, user groups, geographic locations, sites, tenants, applications, or threat risks.

[0083] Intent Categories User intents can be classified into stateful intents (e.g., business policies) and stateless intents. As used herein, a business policy may refer to an intent to be resolved based on the current state of the network (e.g., a stateless intent). The controller device 210 may resolve stateful intents based on the current state of the network. In contrast, a stateless intent may represent a completely declarative way of describing an expected network / computing / storage state without the current state of the network. The controller device 210 may apply an application workflow to convert a stateful intent into a stateless intent. The controller device 210 may detect intent conflicts in a stateful layer (e.g., a business policy layer), provide solutions in the event of a conflict, and synthesize intents. In order to synthesize intents, the controller device 210 may sort intents in the presence of security intents, and / or generate stateless intents.

[0084] Configuring the controller device 210 to apply a policy graph abstraction (PGA) may allow the controller device 210 to express network policies independently. When applying the PGA, the controller device 210 may utilize a graph structure to detect and resolve policy conflicts. When applying the PGA, the controller device 210 may model and synthesize service chaining policies, such as a sequence of middleboxes to traverse, by merging multiple service chaining requirements into a conflict-free synthetic chain.

[0085] In PGA, the model includes vertices and edges. Each vertex in the PGA graph model represents an endpoint group (EPG), and the EPG includes a set of endpoints (EP). EP is the smallest abstract unit to which a policy is applied, such as a server, VM, client device, network, subnet, or end user. EPG includes all EPs that satisfy the membership predicate specified for the EPG. By default, in PGA, no communication is allowed between any EPs. There must be directed edges between EPGs to specify permitted communications in PGA policies. PGA provides graph-based policy analysis, which provides eager synthesis of "network policy" to "conflict-free synthetic policy".

[0086] With respect to PGA, there is a need for intent extensibility. For example, a controller device may include multiple use case applications. For example, a controller device may support a first use case involving a connection service controller (e.g., a service provider connection service VPN, etc.). The controller device may support a second use case to support an SD-WAN controller (e.g., to the core of a customer network). The controller device may support a third use case involving managing security. Initially, the customer installs the connection service to the controller device, and then the customer installs the WAN controller to the controller device. In this PGA example, the business intent model should be extended using the WAN stateless intent. Additionally, the PGA model may need to be extended to manage security, which may require enhancing the intent analysis engine of the PGA system (e.g., conflict detection and resolution).

[0087] To address one or more of the aforementioned aspects of the PGA, the controller device 210 may be configured to determine whether a dependent intent conflicts with a stateful intent applied to a data structure (e.g., the unified graph model 60). In response to determining that the dependent intent conflicts with the stateful intent, the controller device 210 may determine a solution to resolve the conflict between the dependent intent and the stateful intent based on the dependent intent and the stateful intent. For example, the controller device 210 may determine a solution by reordering the intents so that the controller device 210 converts the network address from a first address to a second address and then applies the firewall-allowed intent to the second address. Determining whether intents in a stateful intent layer conflict can improve the performance of detecting conflicts between intents, compared to systems that rely on device-level rules.

[0088] Figure 5 is a conceptual diagram illustrating an example data structure 300 according to the techniques of the present disclosure. The techniques described herein operating in the stateful intent layer may configure the controller device 10 to represent the complete network as a unified graph containing stateless intent. The graph (in Figure 5 300) may include devices and / or sites as vertices, stateless intents (also referred to herein as "edges") as vertices, and endpoints as vertices. The stateless intents represented as vertices may have reference associations with sites. As shown, data structure 300 includes vertex 302 ("NAT intent"). Figure 1 ”), Vertex 304 (“Firewall Intention Figure 1 ”), Vertex 306 (“Firewall Figure 2 ”), Vertex 308 (“SD-WAN Figure 1 ”), vertex 310 (“Site A”), vertex 312 (“Site B”), vertex 320 (“Marketing”), and vertex 322 (“Outlook”).

[0089] In this way, the controller device 10 can represent a "unified intent graph" as a state machine, where "logical groupings" determine the state of the network. The controller device 10 can determine transitions in the intent model by logical groupings including site / device locations (e.g., vertex IDs), and intent policy functions can be attached to intent vertices in the graph (e.g., data structure 300).

[0090] Endpoint groups (EGPs) are discussed below. According to the techniques of the present disclosure, the controller 10 can be configured to use endpoints as part of an EPG. The controller device 10 can maintain the EPG hierarchy as a tree. The controller device 10 can generate a model (e.g., data structure 300) that captures the following: (1) intents and corresponding intent actions; (2) dependencies on other intents; (3) analysis handlers registered for each intent dependency; and (4) an intent policy function for each intent that is configured to return a logical grouping, which describes the intent effect.

[0091] Whenever a change of intent is submitted, the controller device 10 may generate a logical grouping by intent (e.g., an intent policy function). For example, in response to receiving an intent 302 to perform NAT from a first address to a second address (“NAT intent”), Figure 1 ”), the controller device 10 may generate a logical grouping (350) using a NAT intent policy function (e.g., function nat intent policy). The intent policy function acting on the intent may provide an updated transformed grouping. For example, the controller device 10 may apply the NAT intent policy function to the NAT intent of vertex 302 to generate an updated transformed grouping (352) that traverses to vertex 310.

[0092] Controller device 10 may check dependency intent (354), also referred to herein as “intent type,” based on the intent action. For example, controller device 10 may determine that vertex 302 refers to an intent NAT that specifies a dependency type of “firewall allow.”

[0093] Based on the intent dependency type, the intent analysis engine (e.g., analysis handler 27) can determine one or more dependent intents. For example, the controller device 10 can determine the intent of the ancestor edge (e.g., vertex 304) with the firewall allow intent type as a dependent intent. For example, if the intent is a firewall intent including a source endpoint and a destination endpoint, the controller device 10 can traverse the EPG tree to check the edge. The analysis handler (e.g., analysis handler 27) can check whether the intent change (e.g., the NAT intent represented by vertex 302) conflicts with any dependent intent (e.g., the firewall allow intent represented by vertex 304). In response to determining that the intent change conflicts with any dependent intent, the analysis handler can provide a solution. For example, the analysis handler can sort the modified intent. For example, the analysis handler can apply the NAT intent represented by vertex 302 before applying the firewall allow intent represented by vertex 304, in which case the NAT function applies the firewall allow intent represented by vertex 304 to the second address instead of the first address. In some examples, the analysis handler can change the dependent intent. For example, the analysis handler may modify the firewall allow intent represented by vertex 304 to apply to the second address of the NAT intent represented by vertex 302. The analysis handler may append any changes to the solution as a "ChangeList" to the logical grouping. The controller 10 may continue to apply the unified graph (e.g., data structure 300).

[0094] Figure 6 4 is a conceptual diagram illustrating an example controller device 410 configured to perform conflict detection using graph-based stateful intent analysis according to the techniques of the present disclosure. As shown, the controller device 410 may include a business policy and stateful intent module 402 (referred to herein as "intent module 402") and business logic 404. The intent module 402 includes a stateful intent model 430 and a stateful intent analysis 424, which may be graph-based. The business logic 404 may include an intent policy model 420, an intent compilation 422, and a low-level device model 424.

[0095] The controller device 410 (e.g., the stateful intent model 430) can classify intents according to the actions (e.g., intent types) being performed by the corresponding intents. For example, when the action is to connect, the controller device 410 can connect the endpoint. The connection action may include, for example, VPN, peer-to-peer (P2P), virtual LAN (VLAN), or SD-WAN intents. Allow actions may include, for example, firewall allow intents that allow endpoint communication. Block actions (also referred to as "deny" in this article) may include, for example, firewall block intents that block endpoint communication. NAT actions may include, for example, NAT that converts the endpoint IP address. These actions will be extensible. For example, the controller device 410 may support actions including zero or more connections, allows, blocks, NATs, and / or one or more other actions. Each intent definition may be registered with an "intent action type."

[0096] The logical grouping may include an action (eg, connect, allow, block, or NAT), a source ("Src") endpoint, a destination (eg, "Dst") endpoint, and the properties shown in the following table.

[0097]

[0098] Logical groupings can be extended based on new policies supported.

[0099] The controller device 410 can capture intent dependencies as part of the model. For example, a NAT operation may affect a firewall allow action or a firewall block action. In this example, the stateful intent analysis engine 432 can determine the dependency between the NAT action and the firewall action (e.g., allow or block).

[0100] The intent module 402 can determine the transition in the stateful intent model 430 through the grouping and policy functions in the figure. Whenever a new intent is created or updated, the intent module 402 can form a logical grouping based on the intent. For example, the intent module 402 can use the logical grouping {Action: IP Translate, Src: Address2} to determine the NAT intent: NATAddress1 to Address2. In this example, by utilizing the transition function, the intent module 402 will determine the updated grouping: Logical Packet: {Action: IP Translate, Src: Address2, properties: {OldSrc: Address1}}.

[0101] Based on intent dependencies (e.g., actions), the stateful intent analysis engine 432 can determine dependent intents. An analysis handler can be registered for an intent. The intent module 402 with an analysis handler can check whether the intent change conflicts with any dependent intents. If the intent module 402 determines that the intent change conflicts with any dependent intent (e.g., yes), the intent module 402 provides a solution. The intent module 402 can provide a solution to include sorting the modified intent or changing the current intent (e.g., the intent currently being applied). The intent module 402 can attach changes (e.g., sorting the modified intent or changing the current intent) to the group as a "ChangeList". For example, the intent module 402 can attach changes to the group as a "ChangeList" to include {Action:IP Translate, Src:Address2, properties: {OldSrc:Address1, ChangeList: [Intent type:FirewallIntent, uuid:1234, changes]}}.

[0102] The following "playbook" describes an example of how to simulate firewall intent and NAT intent.

[0103]

[0104]

[0105]

[0106]

[0107] The controller device 410 (e.g., the intent module 402) can maintain the EPG hierarchy as a tree. For applications, the controller device 410 (e.g., the intent module 402) can maintain that the Internet is the root node. For source objects, the controller device 410 (e.g., the intent module 402) "any" can include the root node. The EPG can be a server, a VM, a client device, a network, a subnet, or an end user.

[0108] Figure 7 is a conceptual diagram illustrating a first example of the intended ordering of child source nodes and parent source nodes according to the techniques of the present disclosure. For illustrative purposes only, reference is made to Figure 7 Discuss controller device 410.

[0109] Firewall state intents (e.g., allow or deny) may not have any ordered priority for existing firewall intents. Stateful intent analysis engine 432 (also referred to herein as "intent analysis engine") may transform firewall stateful intents by placing them in an "ordered intent" list. Firewall stateful intents may include source endpoints, destination endpoints, and communications. As in PGA, stateful intent analysis engine 432 may model each endpoint group (EPG) as a vertex. These EPGs may be hierarchical. Stateful intent analysis engine 432 may model intent communications (e.g., allow / deny) as edges between EPGs. For example, stateful intent analysis engine 432 may represent a firewall allow between group A and group B as: A is a vertex, B is a vertex; and the allow is an edge (e.g., an arc) between vertex A and vertex B. When adding a new stateful intent, if the new stateful intent includes a "firewall intent", stateful intent analysis engine 432 (e.g., using an analysis handler) may traverse the source endpoints (e.g., source EPG tree) and the destination endpoints (e.g., destination EPG tree). In this example, stateful intent analysis engine 432 may check whether there are any edges between ancestor nodes. If there are any edges between ancestor nodes, stateful intent analysis engine 432 may determine whether at least one ancestor node conflicts with the new stateful intent. In response to determining that at least one ancestor node conflicts with the new stateful intent, stateful intent analysis engine 432 may determine that a conflict has occurred (e.g., a conflict has been triggered). In response to determining that at least one ancestor node conflicts with the new stateful intent, stateful intent analysis engine 432 may place the new stateful intent before the superset intent.

[0110] The stateful intent analysis engine 432 can sort intents based on hierarchical groupings. The stateful intent analysis engine 432 can sort conflicting rules from child source nodes to parent nodes. For example, the stateful intent analysis engine 432 can determine a source EPG ("SRC EPG") and a destination EPG based on the intent. The stateful intent analysis engine 432 can find common ancestor edges. For example, the stateful intent analysis engine 432 can recursively traverse the SRC node tree and the destination node tree in the parent direction. The stateful intent analysis engine 432 can determine whether an edge exists between the SRC node tree and the destination ("DST") node tree. The stateful intent analysis engine 432 can check whether the edge type is dependent on a given intent type. In response to determining that the edge type is dependent on a given intent type (e.g., if it is), the stateful intent analysis engine 432 can place the intent before the intent already discovered in the previous step. In Figure 7In the example of , the stateful intent analysis engine 432 can place the marketing vertex 506 and the salesperson intent vertex 508 before the “all” vertex 502 and the internet intent vertex 504 .

[0111] Figure 8 is a conceptual diagram showing a second example of the intended ordering of child source nodes and parent source nodes according to the technology of the present disclosure. Figure 8 In the example of , stateful intent analysis engine 432 may place marketing vertex 516 and salesperson intent vertex 518 before “all” vertex 512 and internet intent vertex 514. However, a user may be allowed to override the order of intents determined by stateful intent analysis engine 432.

[0112] Fig. 9 is a conceptual diagram illustrating an example of intent ordering of site-specific source nodes and global nodes according to techniques of the present disclosure. A user may submit conflicting intents that may be detected and reported by stateful intent analysis engine 432. For example, marketing vertex 522 and salesperson vertex 524 connected by an allow arc will conflict with marketing vertex 526 and salesperson vertex 528 connected by an allow arc.

[0113] Fig.10 is a conceptual diagram illustrating an example of redundant intent detection according to the technology of the present disclosure. The stateful intent analysis engine 432 can perform redundant intent detection. For example, the stateful intent analysis engine 432 can detect redundant intents submitted by an end user that cause intents to be obscured. The stateful intent analysis engine 432 can detect obscured intents, notify the end user, and delete the obscured intents.

[0114] For example, stateful intent analysis engine 432 may determine a source EPG (SRC EPH) and a destination EPG (DST EPG) based on the intent. Stateful intent analysis engine 432 may find common ancestor edges. For example, stateful intent analysis engine 432 may recursively traverse the SRC node tree and the destination node tree in the parent direction. Stateful intent analysis engine 432 may determine whether an edge exists between the SRC node tree and the DST node tree. Stateful intent analysis engine 432 may check whether the edge types are the same on a given intent type. If the edge types are the same on a given intent type, stateful intent analysis engine 432 may mark the intent as redundant. Fig.10 In the example of , the marketing vertex 536 and the salesperson vertex 538 connected by the allowed arc will be shaded by the "all" vertex 532 and the Internet vertex 534 connected by the allowed arc. In this way, the stateful intent analysis engine 432 can delete the marketing vertex 536 and the salesperson vertex 538.

[0115] Fig.11 is a conceptual diagram illustrating an example of redundant intent resolution according to the techniques of the present disclosure. Stateful intent analysis engine 432 can be configured to perform conflict resolution. For example, stateful intent analysis engine 432 can determine a solution such that site-specific intent takes precedence over global intent. For example, stateful intent analysis engine 432 can place site-specific intent above global intent. Fig.11 In the example of , marketing vertex 542 and salesperson vertex 544 (e.g., level 0) connected by an allowed arc will be above "all" vertex 546 and internet vertex 548 (e.g., level 1) connected by an allowed arc. In this way, stateful intent analysis engine 432 can place site-specific intent (e.g., marketing vertex 542 and salesperson vertex 544) above global intent (e.g., "all" vertex 546 and internet vertex 548).

[0116] The stateful intent analysis engine 432 can verify the intent of direct policy changes or out-of-band (OOB) changes. The administrator can modify the policy directly on the network device. This can be done when the controller device 410 is powered off. The stateful intent analysis engine 432 can verify the direct policy changes or OOB changes with intent as follows. The stateful intent analysis engine 432 can generate intents based on OOB changes. The stateful intent analysis engine 432 can generate logical groupings based on intent changes through the intent policy function. Through the intent analysis handler, the stateful intent analysis engine 432 can detect whether the change conflicts with the existing intent. For example, the stateful intent analysis engine 432 can apply a firewall analysis handler to determine the source EPG (Src EPG) and the destination EPG based on the modified intent. The stateful intent analysis engine 432 can find the ancestor edge by recursively traversing the SRC node tree and the destination node tree in the parent direction. The stateful intent analysis engine 432 can determine whether there is an edge between the SRC node tree and the DST node tree. The stateful intent analysis engine 432 can determine whether the edge type depends on a given intent type. If the edge type depends on a given intent type (eg, if yes), and if the intent is obscured, the stateful intent analysis engine 432 can determine that the intent is invalid and notify the user. In response to determining that the intent is invalid, the stateful intent analysis engine 432 can delete the redundant intent.

[0117] The stateful intent analysis engine 432 may implement stateful intents. When a stateful intent is implemented, the stateful intent analysis engine 432 may take into account existing intents. The stateful intent analysis engine 432 may represent all intents as graph vertices. If multiple intents may be available on a site object, the stateful intent analysis engine 432 may sort the intents by intent type. For example, the stateful intent analysis engine 432 may sort a NAT intent before a firewall intent (e.g., allow or deny). The source endpoints and destination endpoints may include servers, VMs, client devices, networks, subnets, or end users.

[0118] Whenever a new intent is created or updated, the stateful intent analysis engine 432 can form logical groupings based on the intent. For example, for NAT Intent: NAT Address1 to Address2. Logical Packet: {Action: IP Translate, Src: Address2}, the stateful intent analysis engine 432 can apply a transformation function that produces an updated grouping: Logical Packet: {Action: IP Translate, Src: Address2, properties: {OldSrc: Address1}}. Based on intent dependencies (e.g., actions or intent types), the stateful intent analysis engine 432 can determine the dependent intents. Again, analysis handlers are registered for intents. The stateful intent analysis engine 432 can determine whether the intent change conflicts with any dependent intents. If the intent change conflicts with any dependent intents (e.g., if yes), the stateful intent analysis engine 432 can provide a solution. Likewise, the solution can sort the modified intent or change the current intent. The stateful intent analysis engine 432 can attach a "change list" to the grouping to indicate the solution. For example, the stateful intent analysis engine 432 may append a “change list” to include {Action:IPTranslate,Src:Address2,properties:{OldSrc:Address1,ChangeList:[Intent type:FirewallIntent,uuid:1234,changes]}}.

[0119] The stateful intent analysis engine 432 can verify the intent about discovery. There may be obscured intent about discovery because the device rules are misplaced or the intent about discovery is invalid. The stateful intent analysis engine 432 can generate intents from the discovered devices. The stateful intent analysis engine 432 can generate logical groupings based on intent changes through intent policy functions. The stateful intent analysis engine 432 can apply an intent analysis handler to detect whether the intent conflicts with an existing intent. The stateful intent analysis engine 432 can apply a firewall analysis handler to determine the source EPG (Src EPG) and the destination EPG (DST EPG) based on the modified intent. The stateful intent analysis engine 432 can find the ancestor edge by recursively traversing the source node tree and the destination node tree in the child direction. The stateful intent analysis engine 432 can determine whether there is an edge between the source node tree and the destination node tree. The stateful intent analysis engine 432 can determine whether the edge type depends on a given intent type. If the edge type depends on a given intent type (eg, if yes), and if the intent is obscured, the stateful intent analysis engine 432 can determine that the intent is invalid and notify the user. In response to determining that the intent is invalid, the stateful intent analysis engine 432 can delete the redundant intent.

[0120] Controller device 410 (e.g., stateful intent analysis engine 432) can be extensible. For example, controller device 410 can be configured to define new intents, new intent policy functions, and / or new intent analysis handlers. Logical groupings can be extensible to support detecting conflicts. For example, quality of service (QoS) is a property that can be used to detect conflicts. In this example, stateful intent analysis engine 432 can generate logical groupings to include the following.

[0121] Action: Connect / Allow / Block

[0122] Src: Site A,

[0123] Destination: Site B,

[0124] ·QOS: 10Mbps

[0125] ·property:

[0126] The techniques described herein may provide one or more of the following:

[0127] A method for real-time detection of intent-policy conflicts across firewall intents.

[0128] A method for detecting intent-policy conflicts across various intent types in real time.

[0129] A method for providing resolution when conflicts are observed.

[0130] • A method for verifying intent regarding direct policy changes or OOB changes.

[0131] • A method for verifying intent regarding findings from a Brownfield deployment.

[0132] An extensible approach that allows adding new intent types.

[0133] Fig.12 is a flowchart illustrating an example process for determining a solution to a conflict of intent according to the techniques of the present disclosure. For example purposes only, reference is made to Figures 1 to 11 discuss Fig.12 .

[0134] A controller device (e.g., controller device 10, controller device 210, controller device 410, or stateful intent analysis engine 432) may maintain a data structure (600). In some examples, the data structure includes a plurality of vertices and a plurality of edges, each vertex in the plurality of vertices representing a corresponding network device in a plurality of network devices (e.g., network device 12) or a corresponding stateless intent in a plurality of stateless intents, and the plurality of edges defining a relationship between the plurality of vertices. For example, the data structure may be a unified graph model (e.g., see Figure 3 , 5 ).

[0135] A controller device may receive an indication of stateful intent (602). For example, the controller device may receive the indication of stateful intent from a command line interface (CLI). In some examples, the controller device may receive the indication of stateful intent in response to discovering a network device in a plurality of network devices.

[0136] A stateful intent may specify an intended state to be translated into one or more device-level configuration changes for the network device 14. For example, a stateful intent may include a NAT intent, a firewall intent (e.g., allow or deny), or a connection intent (e.g., VPN, P2P, VLAN, or SD-WAN).

[0137] A controller device (e.g., controller device 10, controller device 210, controller device 410, or stateful intent analysis engine 432) may generate logical groupings based on the stateful intent (604). For example, the controller device may generate logical groupings based on intent changes by using intent policy functions (e.g., function firewall intent policy or function NAT intent policy) for vertices in the data structure.

[0138] A controller device (e.g., controller device 10, controller device 210, controller device 410, or stateful intent analysis engine 432) may determine dependent intents of a data structure based on logical groupings (606). For example, the controller device may determine an intent type dependency based on a stateful intent. For example, the controller device may use the data structure to determine the intent type dependency as a firewall-allowed NAT intent. The controller device may determine a vertex from a plurality of vertices that includes an intent type dependency based on a traversal of the logical groupings in the data structure. In this example, the controller device 10 may determine the dependent intent based on a vertex from a plurality of vertices that includes an intent type dependency. For example, the controller device may determine one or more ancestor vertices that include an intent type firewall-allowed.

[0139] A controller device (e.g., controller device 10, controller device 210, controller device 410, or stateful intent analysis engine 432) may determine that a dependent intent conflicts with a stateful intent (608). For example, the controller device may determine that the dependent intent includes configuring a firewall to allow traffic to a first network address and the stateful intent includes a network address translation that translates the first network address to a second network address. In some examples, the controller device may determine whether the stateful intent and the dependent intent conflict, wherein the stateful intent includes a first intent type and the dependent intent includes the first intent type. Examples of intent types may include, for example, a network address translation type, a firewall allow type, and a firewall deny type.

[0140] In response to determining that the dependent intent conflicts with the stateful intent, a controller device (e.g., controller device 10, controller device 210, controller device 410, or stateful intent analysis engine 432) may determine a solution (610) for resolving the conflict between the dependent intent and the stateful intent based on the dependent intent and the stateful intent.

[0141] For example, the controller device may determine a modified stateful intent based on the dependency intent and the stateful intent so that the modified stateful intent does not conflict with the dependency intent. For example, in response to determining that a firewall allowance for a specific address conflicts with a dependency intent including a NAT for changing a network device from a specific network address to a new network address, the controller device may determine a modified firewall allowance for the new network address, rather than the specific network address. In some examples, the controller device may determine a modified dependency intent based on the dependency intent and the stateful intent so that the modified dependency intent does not conflict with the stateful intent. For example, in response to determining that a dependency intent including a firewall allowance for a specific address conflicts with a NAT intent for changing a network device from a specific network address to a new network address, the controller device may determine a modified firewall allowance for the new network address, rather than the specific network address. In some examples, the controller device may change the order of the intents. For example, the controller device may apply the NAT intent before applying the firewall allow intent or deny intent.

[0142] In some examples, the controller device may determine a hierarchical order for applying dependent intents and stateful intents. For example, the controller device may determine that the dependent intent applies to a group. In this example, the controller device may determine that the stateful intent applies to a subset of the group that does not include the entire group. In this example, in response to determining that the dependent intent conflicts with the stateful intent and in response to determining that the stateful intent applies to the subset of the group and the dependent intent applies to the group, the controller device may apply the stateful intent to the subset of the group and avoid applying the dependent intent to the subset of the group.

[0143] In some examples, the controller device may determine that the dependency intent applies globally to the plurality of sites. In this example, the controller device may determine that the stateful intent applies to a subset of the plurality of sites, the subset not including all of the plurality of sites. In this example, in response to determining that the dependency intent conflicts with the stateful intent and in response to determining that the stateful intent applies to the subset of the plurality of sites and the dependency intent applies globally, the controller device may apply the stateful intent to the subset of the plurality of sites and avoid applying the dependency intent to the subset of the plurality of sites.

[0144] A controller device (e.g., controller device 10, controller device 210, controller device 410, or stateful intent analysis engine 432) may output an indication of a solution (612). For example, the controller device may append a change list for the logical grouping. For example, the controller device may append "{Action:IP Translate,Src:Address2,properties:{OldSrc:Address1,ChangeList:[Intent type:FirewallIntent,uuid:1234,changes]}}" to the change list.

[0145] A controller device (e.g., controller device 10, controller device 210, controller device 410, or stateful intent analysis engine 432) may apply one or more device-level configuration changes (614). For example, the controller device may determine one or more device-level configuration changes based on dependency intent and stateful intent. In this example, the controller device may apply one or more device-level configuration changes to at least one network device of network device 14. For example, the controller device may determine one or more device-level configuration changes using dependency intent and modified stateful intent or using modified dependency intent and stateful intent. However, in response, in order to determine that the dependency intent does not conflict with the stateful intent, the controller device may determine one or more device-level configuration changes using dependency intent and stateful intent.

[0146] In some examples, the controller device may determine that the stateful intent is redundant with respect to the dependent intent and append a change list for the logical grouping to indicate that the stateful intent is redundant.

[0147] The techniques described in the present disclosure may be implemented at least in part in hardware, software, firmware, or any combination thereof. For example, various aspects of the described techniques may be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuit systems, and any combination of such components. The term "processor" or "processing circuit system" may generally refer to any of the aforementioned logic circuit systems, alone or in combination with other logic circuit systems or any other equivalent circuit systems. A control unit including hardware may also perform one or more techniques of the present disclosure.

[0148] Such hardware, software, and firmware may be implemented within the same device or within separate devices to support the various operations and functions described in this disclosure. In addition, any unit, module, or component described may be implemented together or individually as a discrete but interoperable logic device. Depicting different features as modules or units is intended to highlight different functional aspects and does not necessarily imply that such modules or units must be implemented by separate hardware or software components. Instead, the functions associated with one or more modules or units may be performed by separate hardware or software components, or may be integrated within a common or separate hardware or software component.

[0149] The techniques described in the present disclosure may also be embodied or encoded in a computer-readable medium (such as a computer-readable storage medium) containing instructions. The instructions embedded or encoded in the computer-readable medium may cause a programmable processor or other processor to perform the method, for example, when executed. The computer-readable medium may include non-transitory computer-readable storage media and transient communication media. Tangible and non-transitory computer-readable storage media may include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electronically erasable programmable read-only memory (EEPROM), flash memory, hard disk, CD-ROM, floppy disk, cassette, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage medium" refers to a physical storage medium, not a signal, carrier wave, or other transient medium.

Claims

1. A system for detecting conflict of intent, the system comprising: Memory; and a processing circuit coupled to the memory, wherein the processing circuit is configured to: Generate logical groupings based on stateful intents; determining a dependency intent of a data structure based on the logical grouping, wherein the data structure comprises a plurality of vertices and a plurality of edges, each vertex of the plurality of vertices representing a corresponding stateless intent of a plurality of stateless intents, and the plurality of edges defining relationships between the plurality of vertices, and wherein to determine the dependency intent of the data structure, the processing circuit is configured to: determining an intent type dependency based on the stateful intent; determining, based on a traversal of the logical grouping from a source of the stateful intent indication to a destination of the stateful intent indication, a vertex among the plurality of vertices that includes the intent type dependency; as well as determining the dependency intent from the vertices including the intent type dependency among the plurality of vertices; as well as In response to determining that the dependency intention conflicts with the state intention, an indication is output. 2 . The system of claim 1 , wherein the indication indicates the conflict between the dependency intent and the state intent. 3 . The system of claim 1 , wherein the indication indicates a solution to resolve the conflict between the dependency intent and the state intent. 4 . The system of claim 1 , wherein the state intent specifies an intended state to be translated into one or more device-level configuration changes for a plurality of network devices.

5. The system of claim 1 , wherein the processing circuit is further configured to: determining a solution to resolve the conflict between the dependency intention and the state intention based on the dependency intention and the state intention, The indication indicates a solution to resolve the conflict between the dependency intention and the state intention.

6. The system according to claim 5, in, To determine a solution, the processing circuit is configured to determine one or more device-level configuration changes based on the dependency intent and the state intent; as well as The processing circuit is further configured to apply the one or more device-level configuration changes to at least one network device among the plurality of network devices.

7. The system according to claim 5, wherein: To determine the solution, the processing circuit is configured to determine a modified state intent based on the dependency intent and the state intent, such that the modified state intent does not conflict with the dependency intent.

8. The system according to claim 5, wherein: To determine the solution, the processing circuit is configured to determine a modified dependency intent based on the dependency intent and the state intent, such that the modified dependency intent does not conflict with the state intent.

9. The system according to claim 5, wherein: To determine the solution, the processing circuit is configured to determine a hierarchical order for applying the dependent intents and the stateful intents.

10. The system according to claim 9, wherein: To determine the hierarchical order, the processing circuit is configured to: determining that the dependency is intended to apply to a group; determining that the stateful intent applies to a subset of the group, the subset not including all of the group; as well as In response to determining that the dependent intent conflicts with the stateful intent, and in response to determining that the stateful intent applies to the subset of the group and the dependent intent applies to the group, applying the stateful intent to the subset of the group and avoiding applying the dependent intent to the subset of the group.

11. The system according to claim 9, wherein: To determine the hierarchical order, the processing circuit is configured to: determining that the dependency is intended to apply globally to multiple sites; determining that the stateful intent applies to a subset of the plurality of sites, the subset not including all of the plurality of sites; as well as In response to determining that a dependent intent conflicts with the stateful intent, and in response to determining that the stateful intent applies to the subset of the multiple sites and the dependent intent applies globally, applying the stateful intent to the subset of the multiple sites and avoiding applying the dependent intent to the subset of the multiple sites.

12. The system according to claim 5, in, To determine the solution, the processing circuit is configured to determine that the stateful intent is redundant with respect to the dependent intent; and Wherein, to output the indication of the solution, the processing circuit is configured to: append a change list for the logical grouping to indicate that the stateful intent is redundant.

13. The system according to claim 5, in, The stateful intent includes: a network address translation that translates a first network address into a second network address; Wherein, the dependency intention includes: configuring the firewall to allow traffic to the first network address; and Wherein, to determine the solution, the processing circuit is configured to modify the dependency intention to configure the firewall to allow traffic to the second network address and avoid configuring the firewall to allow traffic to the first network address.

14. The system according to claim 1, in, The stateful intent includes a first intent type from among a plurality of intent types, and the dependent intent includes a second intent type from among the plurality of intent types that is different from the first intent type.

15. The system of claim 1, wherein: The stateful intent includes the first intent type, and the dependent intent includes the first intent type.

16. The method according to claim 15, wherein: The multiple intent types include: Network address translation type; Firewall permission type; and Firewall deny type.

17. The system of claim 1, further comprising: In response to discovering a network device, the indication of the stateful intent is received.

18. A system according to any one of claims 1 to 17, wherein: The processing circuit is further configured to receive the indication of the stateful intent from a command line interface (CLI) or receive the stateful intent out-of-band from an administrator.

19. A method for detecting conflict of intent, the method comprising: Generating a logical grouping based on the stateful intent by a control device; determining, by a control device, a dependency intent of a data structure based on the logical grouping, wherein the data structure comprises a plurality of vertices and a plurality of edges, each vertex of the plurality of vertices representing a corresponding stateless intent of a plurality of stateless intents, and the plurality of edges defining a relationship between the plurality of vertices, and wherein determining the dependency intent of the data structure comprises: determining an intent type dependency based on the stateful intent; Determining, based on traversal of the logical grouping from a source of the stateful intent indication to a destination of the stateful intent indication, a vertex of the plurality of vertices that includes the intent type dependency; and determining the dependency intent from the vertices among the plurality of vertices including the intent type dependency; and In response to determining that the dependency intention conflicts with the state intention, an indication is output by a control device.

20. A non-transitory computer-readable storage medium comprising one or more instructions that cause a processing circuit to: Generate logical groupings based on stateful intents; determining a dependency intent of a data structure based on the logical grouping, wherein the data structure comprises a plurality of vertices and a plurality of edges, each vertex of the plurality of vertices representing a corresponding stateless intent of a plurality of stateless intents, and the plurality of edges defining relationships between the plurality of vertices, and wherein to determine the dependency intent of the data structure, the processing circuit is configured to: determining an intent type dependency based on the stateful intent; determining, based on a traversal of the logical grouping from a source of the stateful intent indication to a destination of the stateful intent indication, a vertex among the plurality of vertices that includes the intent type dependency; as well as determining the dependency intent from the vertices including the intent type dependency among the plurality of vertices; as well as In response to determining that the dependency intention conflicts with the state intention, an indication is output.

Images