CN112104473A

CN112104473A - Programmable configuration templates in a graphics-based intent controller

Info

Publication number: CN112104473A
Application number: CN201911120910.2A
Authority: CN
Inventors: C·亚; A·贝丁; J·安蒂奇; J·耳; R·沙里夫
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2019-06-18
Filing date: 2019-11-15
Publication date: 2020-12-18
Anticipated expiration: 2039-11-15
Also published as: CN112104473B

Abstract

A controller device manages a plurality of network devices. The controller device is configured to: a configuration template is received for the data structure, the configuration template specifying a set of configuration changes to be applied to a resource of the plurality of resources of the plurality of network devices. The low-level configuration of each respective owned resource in the set of owned resources for the plurality of resources includes a pointer indicating an owner of the respective owned resource. Determining that the set of configuration changes do not conflict in response to determining that the low-level configuration for the resource does not include a pointer indicating that the owner of the resource is not the configuration template; and applying the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources.

Description

Programmable configuration templates in a graphics-based intent controller

The present application claims the benefit of EP application No. EP19382504 filed on 6/18/2019, the entire content of which is incorporated herein by reference.

Technical Field

The present disclosure relates to computer networks, and more particularly to management of network devices.

Background

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

The network configuration service may be performed by a number of different devices, such as routers with service cards and/or dedicated service devices. Such services include connectivity services, such as layer three virtual private network (L3VPN), virtual private local area network service (VPLS), and peer-to-peer (P2P) services. Other services include network configuration services, such as Dot1q VLAN services. Network Management Systems (NMSs) and NMS devices, also referred to as controllers or controller devices, may support these services so that administrators can easily create and manage these high-level network configuration services.

In particular, the user configuration of a device may be referred to as "intent". An intent-based networking system allows an administrator to describe the network/compute/storage state of an intent. User intent may be classified as business policy or stateless intent. A traffic policy or stateful intent may be resolved based on the current state of the network. Stateless intent may be a fully declarative way of describing the intended network/compute/store state without concern for the current network state.

The intent can be represented as an intent data model, which can be modeled using a unified graph. The intent data model can be represented as a graph of connections such that business policies can be implemented across business computing architectures. For example, a data structure may be used to represent a data model, such as, for example, a connection graph having vertices connected by edges and reference (ref) edges. The controller device may model the intent data model as a unified graph. In this way, business policies can be implemented between the intent data models. When modeling intents using a unified graphical model, extending new intent support may extend the graphical model and compilation logic.

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

To simplify the mapping definition for the user, the controller device may be designed to provide the ability to define the mapping in a simple manner. For example, some controller devices provide for the use of speed 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 configured across devices. Different translators may be used when creating, updating and deleting services from the intent data model.

Disclosure of Invention

In general, this disclosure describes techniques to support programmable configuration templates ("configlets") (e.g., configuration profiles applicable to one or more resources) through opaque intents in a graphics-based intent controller. A Network Management System (NMS) device, also referred to herein as a controller device, may use low-level (i.e., device-level) configuration data to configure a network device, for example, expressed in another next generation (YANG) data modeling language. Further, the controller device may manage the network device based on a combination of the configuration template and the intent.

The techniques described herein may allow a controller to automatically perform validation to help ensure that there are no conflicts between different configuration templates and between a configuration template and an intended generation configuration. For example, the controller may identify conflicts and avoid applying configuration templates, rather than overriding configuration templates intended to generate configurations. In this way, the intent generation configuration can support configuration templates while ensuring that there is no conflict between configuration templates and intent generation configurations.

In one example, a method comprises: receiving, by a controller device that manages a plurality of network devices and for a data structure, a configuration template that specifies a set of configuration changes to be applied to a resource of a plurality of resources of the plurality of network devices, the data structure including a plurality of nodes and a plurality of edges, each node of the plurality of nodes representing a respective network device of the plurality of network devices, and the plurality of edges defining relationships between the plurality of nodes, wherein a low-level configuration of each respective owned resource of a set of owned resources of the plurality of resources includes a pointer that indicates an owner of the respective owned resource. The method further comprises the following steps: determining, by the controller device and in response to determining that the low-level configuration for the resource does not include a pointer indicating that the owner of the resource is not a configuration template, that the set of configuration changes does not conflict with the set of owned resources, and applying, by the controller device and in response to determining that the set of configuration changes does not conflict with the set of owned resources, the set of configuration changes to the resource.

In another example, a controller device to manage a plurality of network devices, the controller device comprising one or more processing units implemented in circuitry and configured to: receiving, for a data structure, a configuration template specifying a set of configuration changes to be applied to a resource of a plurality of resources of a plurality of network devices, the data structure comprising a plurality of nodes and a plurality of edges, each node of the plurality of nodes representing a respective network device of the plurality of network devices and the plurality of edges defining relationships between the plurality of nodes, wherein a low-level configuration of each respective owned resource of a set of owned resources of a plurality of resources includes a pointer indicating an owner of the respective owned resource. The one or more processing units are further configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration of the resource does not include a pointer indicating that the resource owner is not a configuration template, and apply the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources.

In another example, a computer-readable storage medium has instructions stored thereon that, when executed, cause a processor of a controller device that manages a plurality of network devices to receive a configuration template for a data structure that specifies a set of configuration changes to be applied to resources of a plurality of resources of the plurality of network devices, the data structure including a plurality of nodes and a plurality of edges, each node of the plurality of nodes representing a respective network device of the plurality of network devices, and the plurality of edges defining relationships between the plurality of nodes, wherein a low-level configuration of each respective owned resource of a set of owned resources of the plurality of resources includes a pointer that indicates an owner of the respective owned resource. The instructions are also processor: in response to determining that the low-level configuration for the resource does not include a pointer indicating that the resource owner is not a configuration template, determining that the set of configuration changes does not conflict with the set of owned resources, and in response to determining that the set of configuration changes does not conflict with the set of owned resources, applying the set of configuration changes to the resource.

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.

Drawings

Fig. 1 is a block diagram illustrating an example of elements of an enterprise network including upgrades using a management device.

FIG. 2 is a block diagram illustrating an example set of components for the management device of FIG. 1.

FIG. 3 is a conceptual diagram illustrating an example unified graph model for the intent data model.

FIG. 4 is a conceptual diagram illustrating example conflict detection between intent and configuration templates.

FIG. 5 is a conceptual diagram illustrating an example configuration template and configuration template endpoints as a graph.

FIG. 6 is a conceptual diagram illustrating an example configuration template system.

FIG. 7 is a conceptual diagram illustrating an example data transformation.

FIG. 8 is a conceptual diagram illustrating example batch association by tag.

Fig. 9 is a conceptual diagram illustrating intent enhancement.

FIG. 10 is a flow diagram illustrating an example process for managing network devices using a combination of configuration templates and intents.

Like reference numerals refer to like elements throughout the drawings and the description.

Detailed Description

The present disclosure is directed to a controller that supports intent-based workflow to manage a network. For example, a user (e.g., an administrator) may write a conversion program that converts high-level configuration instructions (e.g., instructions according to an intent data model, which may be represented as a unified graphics model) into low-level configuration instructions (e.g., instructions according to a device configuration model), which may be applied to resources of a network. As part of the configuration service support, a user/administrator may provide an intent data model and a mapping between the intent data model and the device configuration model.

Such controllers may support configuration templates (e.g., configuration profiles that may be applied to one or more resources). For example, a configuration template may represent a tool that applies a set of low-level configuration instructions directly to a set of resources of a network. For example, a user may apply a configuration change to multiple resources using a single configuration template. In this way, the configuration template may allow a user to quickly apply the configuration, thereby reducing complexity.

However, some systems may not support a full lifecycle of configuration templates. For example, the system may not be able to determine if a configuration template change conflicts with a previously applied configuration change, which may be considered an out-of-band change. In this case, the system may not be able to verify the configuration template. For example, if a user wants to configure a port setting for a resource, the user may create a port configuration template and apply the port configuration template to the managed network device. In this example, a user may create and apply one or more configuration templates on the same port. Applying multiple configuration templates on the same port may result in conflicts between configuration templates, which may result in incomplete or incompatible configurations.

Further, the system may have a device profile and a node profile each attached to the managed device (this is another way of stating that such profiles are associated with the managed device). Additional device profiles and node profiles may not be attached to resources (e.g., controller management and non-management). In such systems, there may be no way to detect conflicts between profiles, which may be referred to herein as an opaque intent graph model.

In accordance with the techniques described herein, a configuration template may support an intent-based system for customizing intents and/or for supporting elements and network functions that may not be supported by an intent workflow. Techniques such as those described herein provide a programmatic way to model and perform validation on configuration templates in a managed network in order to reduce (and possibly eliminate) conflicts that may lead to an intended failure. In some examples, the configuration template may be allocated on any resource. Examples of resources may include, but are not limited to, devices, ports, areas, virtual networks (vlans), routing instances, configuration resource objects, or other resources, for example. In some examples, the resources may be managed or unmanaged by the controller device. The resources may be managed within the controller device, for example, or may be any path that exists directly on the device in the configuration. In some examples, the controller device may be configured to allow configuration templates to coexist with the intent. For example, the controller device may be configured to verify the configuration template, potentially ensuring that the configuration template does not override the intent-to-generate configuration. The techniques described herein may also allow the controller device to enhance the configuration through the configuration template. In some examples, the controller device may apply configuration templates to manage arbitrary configurations. In some examples, the controller device may be configured to detect conflicts across configuration templates and/or intents.

Further, the controller device may be configured to apply the configuration template to any tags associated with the resources. The controller device may be configured to model the resource or the resource may be retrieved directly from the device database as needed. The controller device may be configured to mark resources on the device (e.g., element). In this way, configuration templates can be easily applied to multiple resources.

Fig. 1 is a block diagram illustrating an example of elements comprising an enterprise network 2 managed using a controller device 10. Managed elements 14A-14G (collectively, "elements 14") of enterprise network 2 include network devices that are interconnected via communication links to form a communication topology to exchange resources and information. Element 14 (also commonly referred to as a network device or remote network device) may comprise, for example, a router, switch, gateway, bridge, hub, server, firewall or other Intrusion Detection System (IDS) or intrusion prevention system (IDP), computing device, computing terminal, printer, other network device, or a combination of these devices. Although described in this disclosure as transporting, transmitting, or otherwise supporting packets, enterprise network 2 may transport data in accordance with any other discrete data units defined by any other protocol, such as cells defined by the Asynchronous Transfer Mode (ATM) protocol, or datagrams defined by the User Datagram Protocol (UDP). The communication link interconnecting the elements 14 may be a physical link (e.g., optical, copper, etc.), wireless, or any combination thereof.

Enterprise network 2 is shown coupled to a 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 Web servers, application servers, public databases, media servers, end-user devices, and other types of network resource devices and content.

Controller device 10 is communicatively coupled via enterprise network 2Coupled to the element 14. In some examples, the controller device 10 forms part of a device management system, although only one device of the device management system is shown in fig. 1 for purposes of illustration. The controller device 10 may be directly or indirectly coupled to the various elements 14. Once elements 14 are deployed and activated, administrator 12 uses controller device 10 (or a plurality of such management devices) to manage network devices using a device management protocol. One example device protocol is the Simple Network Management Protocol (SNMP), which allows the controller device 10 to traverse and modify a Management Information Base (MIB) that stores configuration data in each of the managed elements 14. Another example device protocol may include NETCONF, however, the description described herein may be used with other device protocols. More details of the SNMP Protocol can be found in Harrington et al, RFC 3411, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management frames," Network Working Group, the Internet Engineering Task Force draft, December 2002http://tools.ietf.org/html/rfc3411Are herein incorporated by reference in their entirety. 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 are found in Enns et al, RFC6241, "Network Configuration Protocol (NETCONF)," Network work Group, the Internet Engineering Task Force draft, June 2011, which is available at https:// tools.

In common practice, the controller devices 10 and elements 14, also referred to as Network Management Systems (NMSs) or NMS devices, are centrally maintained by the IT team of the enterprise. An administrator 12 interacts with the controller device 10 to remotely monitor and configure the elements 14. For example, administrator 12 may receive alerts from controller device 10 regarding any of elements 14, view configuration data for elements 14, modify configuration data for elements 14, add new network devices to enterprise network 2, remove existing network devices from enterprise network 2, or otherwise manipulate enterprise network 2 and the network devices therein. Although described with respect to enterprise networks, the techniques of this disclosure are applicable to other network types, both public and private, including LANs, VLANs, VPNs, and the like.

In some examples, administrator 12 uses controller device 10 or a local workstation to interact directly with element 14, for example, through telnet, Secure Shell (SSH), or other such communication session. That is, element 14 typically provides an interface for direct interaction, such as a Command Line Interface (CLI), web-based interface, Graphical User Interface (GUI), or the like, through which a user may 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 through telnet, Secure Shell (SSH), hypertext transfer protocol (HTTP), or other network sessions, to enter text according to a defined grammar to submit commands to managed elements. In some examples, a user initiates an SSH session 15 with one of the elements 14 (e.g., element 14F) using the controller device 10 to directly configure element 14F. In this manner, a user may provide commands to the element 14 in a format for direct execution.

In addition, the administrator 12 may also create scripts that may be submitted by the controller device 10 to any or all of the elements 14. For example, in addition to the CLI interface, the element 14 also provides an interface for receiving scripts which 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 element 14. The script may conform to, for example, an extensible markup language (XML) or another data description language.

The administrator 12 uses the controller device 10 to configure the elements 14 to specify certain operational characteristics that may achieve the goals of the administrator 12. For example, the administrator 12 may specify particular operational policies for the element 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 management of configuration data in the managed network elements 14, such as the SNMP protocol or the network configuration protocol (NETCONF) protocol or a derivative thereof, such as the seebo device management interface, to perform the configuration. Generally, NETCONF provides a mechanism for configuring network devices and uses extensible markup language (XML) based data encoding for configuration data, which may include policy data. NETCONF is described in Enns, "NETCONF Configuration Protocol," Network work Group, RFC4741, Dec.2006, available at tools. The controller device 10 may establish a NETCONF session with one or more of the elements 14.

The controller device 10 may be configured to compare the new intent data model to an 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.

The intent Data model may be a unified graphics model, and the low-level Configuration Data may be represented by YANG, which is described in Bjorklund, "YANG-A Data Modeling Language for the Network Configuration Protocol (NETCONF)," Internet Engineering Task Force, RFC6020, Oct.2010, which is available at tools. In some examples, the intent data model may be represented by YAML rather than markup language (YAML). The controller device 10 may include various reactive mappers for converting the intent data model differences. These functions are configured to accept an intent data model (which may be expressed as a structured input parameter, for example, according to YANG or YAML). The functions are also configured to output a corresponding set of low-level device configuration data changes, such as device configuration additions and removals. I.e. y₁＝f₁(x),y₂＝f₂(x),…y_N＝f_N(x)。

The controller device 10 can use YANG modeling for the intent data model and the low-level device configuration model. This data may contain relationships between YANG entities such as list items and containers. Traditionally, controller devices do not support configuration management functions in real time. As discussed in more detail below, the controller device 10 can convert a YANG data model to a database model and convert a YANG validation to a data validation. Techniques for managing NETWORK DEVICES USING a graphical model for high-level configuration data are described in U.S. patent application No.15/462,465, "configuration AND MANAGING NETWORK DEVICES USING PROGRAM OVERLAY ON yam-BASED GRAPH data," filed ON 2017, 3, 17, the entire contents of which are incorporated herein by reference.

The controller device 10 may receive data from one of the administrators 12 that represents any or all of the creation, update, and/or deletion actions with respect to the unified intent data model. The controller device 10 may be configured to use the same compilation logic for each of the creation, updating and deletion as applied to the graphical model.

Typically, a controller, such as controller device 10, uses a hierarchical data model for intent, a low level data model, and resources. The hierarchical data model may be based on YANG or YAML. As described above, the hierarchical data model may be represented as a graph. Modern systems have supported intentions for simplifying network management. The intent is to be declarative. To achieve the intent, the controller device 10 attempts to select the optimal resource.

Controller device 10 may be configured to support configuration templates, which may allow administrator 12 to quickly apply a set of low-level configuration changes to elements 14. Further, controller device 10 may be configured to support intent-based configurations, which may allow administrator 12 to provide stateless intent for controller device 10 to transition to a low-level set of configuration changes for elements 14. However, in some examples, administrator 12 may request controller device 10 to apply a configuration template that may apply a set of low-level configuration changes to elements 14 that conflict with low-level configuration changes previously applied to satisfy the stateless intent. In such a case, applying the configuration template may result in the controller device 10 failing to satisfy the stateless intent. For example, when administrator 12 requests a particular bandwidth between

elements

14A and 14D, controller device 10 may not be able to provide the particular bandwidth after applying the low-level configuration changes to the configuration template of element 14.

In general, the techniques described herein may allow for the use of configuration templates (e.g., configuration profiles to which one or more resources may be applied) while supporting an intent-based system for customizing an intent. For example, the controller device 10 may be configured to receive, for a data structure, a configuration template specifying a set of configuration changes to be applied to the resources of the element 14. For example, administrator 12 may be configured to receive a configuration template from administrator 12 that specifies a set of configuration changes (e.g., Virtual Private Network (VPN) connections, Label Switched Path (LSP) connections, etc.) to be applied to a resource of element 14 (e.g., element 14A).

In some examples, the low-level configuration for each respective owned resource in the set of owned resources in the plurality of resources includes a pointer indicating an owner of the respective owned resource of element 14. For example, the controller device 10 may have generated a low-level configuration for the set of owned resources of the element 14 based on the intent generation configuration (e.g., using the intent provided by the administrator 12). In this example, the controller device 10 may have modified the low-level configuration to include a pointer indicating that the owner of the set of owned resources is intended to generate the configuration. In another example, the controller device 10 may have generated a low-level configuration for the set of owned resources based on a previously applied configuration template. In this example, the controller device 10 may have modified the low-level configuration to include a pointer to a configuration template indicating that the owner of the set of owned resources is a previous application.

The controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer indicating that the owner of the resource is not a configuration template. For example, the controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the set of configuration changes does not change resources controlled or owned by a configuration template intended to generate the configuration or previously applied.

The controller device 10 may be configured to apply the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources. For example, the controller device 10 may apply the set of configuration changes in response to determining that the set of configuration changes does not change the resources controlled or owned by the configuration template intended to generate the configuration or previously applied. However, in response to determining that the set of configuration changes resources controlled or owned by the configuration template intended to generate the configuration or previous application, the controller device 10 may be configured to avoid applying the set of configuration changes. In some examples, the controller device 10 may be configured to provide an alert to the administrator 12 in response to determining that the set of configuration changes a resource controlled or owned by a configuration template intended to generate the configuration or previously applied. In this manner, the controller device 10 may be configured to allow the use of configuration templates while supporting an intent-based system for customizing intent.

To process the configuration template, the controller device 10 may be configured to apply a configuration change to the resource of the element 14, which may conflict with the previously applied intent-generating configuration, which may result in the element 14 being configured in the wrong state. Configuring the components 14 to an error state may result in slower operating speeds of the components 14 or fewer connections between the components 14 (resulting in less redundancy and less reliability). Furthermore, applying a configuration change to the resource of the element 14 that conflicts with the previously applied intent generation configuration may result in the controller device 10 failing to meet the intent of the intent generation configuration, resulting in frustration for the user.

To help ensure that applying the configuration template does not result in a conflict with the previously applied intent generation configuration or the previously applied configuration template, the controller device 10 may be configured to perform a verification of the configuration template in order to reduce (and possibly eliminate) conflicts that may result in an intent exception. For example, the controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer indicating that the owner of the resource is not a configuration template, and apply the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources. Configuring the controller device 10 to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer indicating an owner of the resource may help prevent the configuration template from conflicting with the previously applied intent-to-generate configuration and the previously applied configuration template, which may help prevent configuring the element 14 to an error state, thereby improving operation of the controller device 10.

FIG. 2 is a block diagram illustrating an example set of components for the controller device 10 of FIG. 1. In this example, the controller device 10 includes a control unit 22, a network interface 34, and a user interface 36. Network interface 34 represents an example interface that may communicatively couple controller device 10 to an external device, such as one of elements 14 of FIG. 1. 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 of 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, although only one network interface is shown for purposes of example.

Control unit 22 represents any combination of hardware, software, and/or firmware for implementing the functions attributed to control unit 22 and its constituent 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. In general, the processing elements 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 circuitry, as well as any combinations of such components. Furthermore, the processing unit is typically implemented using fixed and/or programmable logic circuits.

User interface 36 represents one or more interfaces through which a user, such as administrator 12 (FIG. 1), interacts with controller device 10, e.g., to provide input and receive output. For example, the user interface 36 may represent one or more of a monitor, keyboard, mouse, touch screen, touch pad, speaker, camera, microphone, and the like. Furthermore, although in this example the controller device 10 comprises a user interface, the administrator 12 need not interact directly with the controller device 10, but may remotely access the controller device 10, e.g. via the network interface 34.

In this example, 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 a user interface module 38 to receive input from the user interface 36 and/or to provide output to the user interface 36. The control unit 22 also executes a network interface module 32 to send and receive data (e.g., packets) via a 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.

The functions of the control unit 22 may be implemented as one or more processing units in fixed or programmable digital logic circuits. Such digital logic circuitry may comprise one or more microprocessors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or any other equivalent integrated or discrete logic circuitry, as well as any combinations of such components. When implemented as programmable logic circuits, the control unit 22 may further include one or more computer-readable storage media that store hardware or firmware instructions to be executed by the processing unit of the control unit 22.

Control unit 22 executes management module 24 to manage various network devices, such as elements 14 of fig. 1. Management of network devices includes, for example, configuring network devices according to instructions received from a user (e.g., administrator 12 of fig. 1), and providing the user with the ability to submit instructions to configure the network devices. Management of the network device also includes upgrading the network device with updated software, such as an updated software image. In this example, management module 24 also includes a configuration module 26 and a translation module 28.

Management module 24 is configured to receive configuration data from a user, such as administrator 12, for the intended unified graphical modeling of a managed collection of network devices. Such configuration data for intent-unified graphical modeling may be referred to as an "intent-data model". Over time, the user may update the configuration data, for example to add a new service, remove an existing service, or modify an existing service executed by the managed device. The unified intent data model can be constructed from, for example, YANG or YAML. The graphical model may include a plurality of vertices connected in a hierarchical manner by edges. In YANG, the edges of the graphics model are represented by "LEAFAREF" elements. In the case of YAML, such an edge can be represented by a "ref" edge. Similarly, parent-child vertex relationships may be represented by "having" edges. For example, the vertex of element a is intended to mean that the vertex of element B with an edge is used and can be understood as "element a with element B". In some examples, management module 24 also provides the user with the ability to submit a reactive mapper that conversion module 28 executes to transform the intent data model into device-specific low-level configuration instructions.

The controller device 10 further comprises a configuration database 40. Configuration database 40 may include data structures, such as elements 14, that describe the network devices being managed. The configuration database 40 may serve as an intent data store that may be used to persist and manage a collection of intent data models. For example, configuration database 40 may include information indicating device identifiers (such as MAC and/or IP addresses), device types, device vendors, device classes (e.g., routers, switches, bridges, hubs, etc.), or the like. 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) for the managed device (e.g., element 14). The configuration database 40 may include a database that includes a unified intent data model. In some examples, configuration database 40 may store a low-level configuration that includes, for each respective owned resource in the set of owned resources, a pointer indicating an owner of the respective owned resource of element 14.

Configuration template module 27 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer indicating that the owner of the resource is not a configuration template. For example, the configuration template module 27 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining, using the configuration database 40, that the set of configuration changes does not change resources controlled or owned by the intent-generating configuration or previously applied configuration template.

Although user interface 36 is described for purposes of example as allowing administrator 12 (fig. 1) to interact with controller device 10, other interfaces may be used in other examples. For example, the controller device 10 may include a representational state transfer (REST) client (not shown) that may serve as an interface to another device through which the administrator 12 may configure the controller device 10. Likewise, the administrator 12 may configure the elements 14 with interaction with the controller device 10 through a REST client.

Management module 24 may model configuration database 40 as a graphical database representing a YANG configuration data element. YANG specifies various types of data structures including lists, leaf lists, containers with status, and features. Management module 24 may model the list, the container and feature with state, and the top level container as vertices in a graph database. Alternatively, the configuration database 40 may represent YAML configuration data elements.

After the graph database is built, management module 24 may perform operations on the data of the graph database. For example, the management module 24 may map Netconf-based operations such as get-config, get-config with filters, and edge-config to a graphical query language query, such as a Gremlin query. Gremlin is described in gremlandocs, spmallette, documentup, com and githu, com/tinkerp/Gremlin/wiki. If the condition attribute changes, management module 24 may execute the condition mapped to the vertices and edges of the graph database. In response to the condition, management module 24 may process additional changes that are handled as functions, as discussed in more detail below. Management module 24 may further update all changes in transaction semantics.

Configuration template module 27 may be configured to receive, for a data structure, a configuration template specifying a set of configuration changes to be applied to the resources of element 14. For example, user interface 36 may receive a configuration template from administrator 12, the configuration template specifying: a set of configuration changes (e.g., Virtual Private Network (VPN) connections, Label Switched Path (LSP) connections, etc.) to be applied to the resources of element 14 (e.g., element 14A).

In some examples, configuration database 40 may store a low-level configuration for each respective owned resource in the set of owned resources, the low-level configuration including a pointer indicating the owner of the respective owned resource of element 14. For example, the configuration template module 27 may have generated a low-level configuration for the set of owned resources of the element 14 based on the intent generation configuration (e.g., using the intent received by the user interface 36). For example, the translation module 28 executes to translate the intent data model for intent received by the user interface 36 into device-specific low-level configuration instructions that include a pointer indicating that the owner of the owned resource set is an intent to generate a configuration. In another example, in response to user interface 36 receiving a configuration template, configuration template module 27 may have generated a low-level configuration for the set of owned resources. In this example, configuration template module 27 may have modified the low-level configuration of the data structure to include a pointer to a configuration template that indicates that the owner of the set of owned resources is a previous application.

The configuration template module 27 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer indicating that the owner of the resource is not a configuration template. For example, the configuration template module 27 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining, using the configuration database 40, that the set of configuration changes does not change resources controlled or owned by the configuration template intended to generate the configuration or previously applied.

The configuration template module 27 may be configured to apply the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources. For example, the configuration template module 27 may apply the set of configuration changes to the element 14 in response to determining that the set of configuration changes does not change the resources controlled or owned by the configuration template intended to generate the configuration or previously applied. In some examples, configuration template module 27 may be configured to update a data structure stored by configuration database 40 to indicate that a set of configuration changes has been applied to the resources of element 14. However, in response to determining that the configuration set changes resources controlled or owned by the configuration template intended to generate the configuration or previous application, the configuration template module 27 may be configured to avoid applying the configuration change set. In some examples, configuration template module 27 may be configured to provide an alert to user interface 36 via user interface 36 in response to determining that the set of configurations changes a resource controlled or owned by a configuration template intended to generate the configuration or previously applied. In this manner, the configuration template module 27 may be configured to allow the use of configuration templates while supporting an intent-based system for customizing intent.

FIG. 3 is a conceptual diagram illustrating an example unified graphics model 60 for the intent data model. The process shown in fig. 3 may represent an example of how the controller device 10 may generate an intent generation configuration. The unified graphical model 60 may be an example of a data structure stored by the configuration database 40 of FIG. 2. In this example, unified graphics model 60 includes nodes A62, B64, and C66, among others, which may represent respective network devices (e.g., element 14). As shown, the unified graph model 60 may include edges that define relationships between a plurality of nodes A62, B64, and C66. The edge connecting node B64 and node C66 via LSP2, for example, may define an RSVP LSP between node B64 and node C66.

Initially, unified graphics model 60 may include neither VPN 68, VPN 72, and VPN 78, nor Optical 180, Lambda 82, Optical 184, and Lambda 86. As a result of the modification by the intention data model update, node a 62 is coupled to node B64 via VPN 68 and LSP170, node B64 is coupled to node C66 via VPN 72 and LSP274, and node C66 is coupled to node a 62 via VPN 78 and LPS 376. In addition, additional nodes Optical 180, Lambda 82, Optical 184, and Lambda86 are added between node B64 and node C66 as additional capacity is required for Optical purposes.

Stateful business policies may be written above the stateless intent layer. For example, the user may declare the intent "provide a high bandwidth VPN connection between sites A, B and C, with bandwidth … between A-B, B-C, C-A". This may lead to various stateless intents. Stateful intents may be compiled into L3 VPNs (overlay channels) and transport mechanisms that provide the required bandwidth between a-B, B-C, C-a. For example, the transport mechanism may include: RSVP LSP between A-B with 30Mbps, RSVP LSP between B-C with 50Mbps, and RSVP LSP between C-A with 80 Mbps. In this case, it may be necessary to create an RSVP-LSP with 80Mbps between C-A. There may be situations where more capacity is needed, and therefore there may be a further intention "optical intention: increasing the capacity between C-a. "if C-A already has a 70Mbps connection, the stateless intent may provide a new 10G lambda between C-As on the optical network.

When implementing stateful intent, a controller device, such as controller device 10, may need to consider existing stateless intent across endpoints as well as the current state. In the above examples, to perform various intents, the controller device 10 may query the connected graph (including the stateless intent) and create/modify the stateless intent as needed. Techniques related to the use of a unified graphics model and intent are described in U.S. application No.15/462,465 filed on 2017, 3, 17, which is incorporated herein by reference in its entirety. Thus, the intent data model can be represented using a unified graphical model. The intent data model (i.e., unified graphics model) can be extended as more use cases are added. Moreover, the use of a unified graphics model allows for endpoint-based (e.g., through query graphics) retrieval of intent.

However, even when considering existing stateless intents, the controller device may apply a configuration template that causes the controller device to no longer implement stateful intents, which may result in the controller device being unable to maintain the intent generation configuration. For example, the controller device 10 may be configured to receive a configuration template for the data structure that specifies a set of configuration changes to be applied to node B64 and node C66. For example, a configuration template is received that specifies a set of configuration changes to LSP274 that reduces the bandwidth from 50Mbps to 30 Mbps. In this example, applying the configuration template causes the controller device to no longer configure element 14 to implement an RSVP LSP between B-cs at 50Mbps, which may result in the controller device failing to satisfy the stateful intent of a particular bandwidth between node a 62 and node C66.

In accordance with the techniques described herein, the controller device 10 may be configured to include, for each respective owned resource of the set of owned resources, a pointer indicating the owner of the respective owned resource of the element 14. For example, the controller device 10 may generate a low-level configuration for the set of owned resources of the element 14 based on the intent generation configuration represented by the unified graphics model 60. In this example, the controller device 10 may modify the low-level configuration to include a pointer indicating that the owner of the owned resource set is intended to generate the configuration.

In this example, the controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer indicating that the owner of the resource is not a configuration template. For example, the controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the set of configuration changes does not change resources controlled or owned by a configuration template intended to generate the configuration or previously applied. For example, the controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration for the resource does not include a pointer indicating an owner of the resource. In some examples, the controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration of the resource includes a pointer indicating an owner of the resource and that the pointer indicates that the owner is a configuration template.

The controller device 10 may be configured to apply the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources. For example, the controller device 10 may apply the set of configuration changes in response to determining that the set of configuration changes does not change the resources controlled or owned by the intent-generating configuration represented by the unified graphics model 60.

FIG. 4 is a conceptual diagram illustrating example conflict detection between intent and configuration templates. In the example of fig. 4, the controller device 10 may be configured to determine in-band collisions and out-of-band collisions. In an in-band conflict, an element configuration template may configure a Command Line Interface (CLI), which may be configured by an intent, which may conflict with the intent.

In an out-of-band (OOB) conflict, there may be OOB changes that may conflict with the configuration template configuration and/or the intended configuration. Thus, in some examples, the controller device 10 may be configured to apply a compilation that maintains

pointers

98A, 98B, 98C, 98D (collectively pointers 98) (e.g., dependencies), as shown in fig. 4. For example, the controller device 10 may apply the set of configuration changes to the owned resources in the set of owned resources and modify the low level configuration to include a pointer indicating the owner of the owned resources. For example, the pointer 98A may indicate that the owner of resources 1 and 2 is the first configuration template intent 92 of the intent data model 88, while the pointer 98C may indicate that the owner of resource 4 is the abstract configuration 94 of the abstract configuration model 89 of the first device. In this example, the pointer 98B indicates that the intent 93 of the intent data model 88 is the owner of the abstract configuration 94, and the pointer 98D indicates that the intent 93 is the owner of the abstract configuration 95 and the abstract configuration 96 of the abstract configuration model 90 of the second device.

That is, for example, the controller device 10 may be configured to apply a set of configuration changes to the owned resource (e.g., resource 4) based on the intent 93 and modify a low-level (e.g., native) configuration of the network device to include

pointers

98B, 98C indicating that the owner of the owned resource points to the representation of the intent 93. Similarly, the controller device 10 may apply a set of configuration changes to an owned resource in the set of owned resources based on a previously applied configuration template and modify the low-level configuration to include a pointer to the owner of the owned resource to point to a representation of the previously applied configuration template.

In the example of fig. 4, the controller device 10 may be configured to use the pointer 98 in applying the abstract configuration resource configuration to determine which intents are creating objects. Similarly, the controller device 10 may be configured to determine which resources (e.g., configuration knobs) are generated by the intents 93 and/or the configuration templates 92 and/or the abstract configurations 94-96 when the device 1 native configuration model 91 is applied for the first device.

The controller device 10 may be configured to determine that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer indicating that the owner of the resource is not a configuration template, and apply the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources. For example, if the configuration template intent 92 attempts to override the abstract configuration 94 (e.g., by configuring the resource 4), the controller device 10 may output an indication that a failure has occurred and will avoid applying the configuration template intent 92. Example pseudo code showing a native configuration with pointers is as follows.

In the pseudo code for native configuration with pointers described above, the metadata may represent a pointer, "src _ uuid": "1234" may represent an example identifier of a pointer, "1234", while "src _ type": "Firewall" may represent an example Intent of a region named "trust," which may be an example of a resource.

If the template generation increment is configured, as follows:

in the aforementioned pseudo code for making changes by the configuration template, the instruction would request the controller device 10 to delete the zone named "trust", which if applied would result in a potential conflict with the firewall intent.

Example pseudo code illustrating an example collision detection algorithm is as follows.

Program detectConflict (input _ delta, config)

Input delta generated by a configuration template change or an intent change

For each configuration in the input delta

The elements in the resulting configuration

Checking whether the element or parent resource has metadata

If metadata exists

Identifying whether the configuration is owned by some other intent/configuration template

If so, return marking it as failed

In the aforementioned pseudo code for collision detection, the controller device 10 may determine that a configuration change (e.g., "input _ delta") is generated by the configuration template. In this example, the controller device 10 may determine a native configuration (e.g., an element in the configuration) for each resource changed by the configuration change, and check whether the native configuration has a pointer (e.g., "meta-data": [ { "src _ uuid": "1234", "src _ type": "Firewall Intent"). In this example, if a pointer is present, the controller device 10 may identify whether the pointer specifies that the resource is owned by another configuration template or an intent-based configuration (e.g., by some other intent/configuration template). If the pointer specifies that the resource is owned by another configuration template or an intent-based configuration (e.g., "if yes"), the controller device 10 may mark the configuration template (e.g., the configuration template that generated the delta) as failed and return. However, if the pointer specifies that the resource is not owned by another configuration template or Intent-based configuration (e.g., does not include "meta-data": [ { "src _ uuid": "1234", "src _ type": "Firewall Intent", or metadata specifies the owner as a configuration template), the controller device 10 may skip a portion of the pseudo-code described above (e.g., the return marking it as failed) and apply the generation of the configuration change (e.g., "input _ delta") from the configuration template.

In this way, the controller device 10 may be configured to apply conflict detection to avoid conflicts between configuration templates and intents. For example, the controller device 10 may be configured to use a low-level configuration that maintains reference information to intent and/or configuration templates. For example, the controller device 10 may be configured to generate a low-level configuration that includes, for each respective owned resource, a pointer (e.g., pointer 98, "meta-data": [ { "src _ uuid": 1234"," src _ type ": Firewall Intent" ", etc.) that indicates the owner of the respective owned resource. When applying the configuration template to the network device, the controller device 10 may verify whether the configuration template configuration is affecting the intent generation configuration.

For example, the controller device 10 may be configured to determine that the set of configuration changes to the resource does not conflict with the set of owned resources in response to determining that the low-level configuration does not include a pointer (e.g., "meta-data": { "src _ uuid": "1234", "src _ type": Firewall Intent ") indicating that the owner of the resource is not a configuration template, and may apply the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict. For example, in response to determining that the low-level configuration does not include any pointer to the resource, the controller device 10 may determine that the set of configuration changes does not conflict with the set of owned resources. In another example, the controller device may determine that the set of configuration changes specified by the particular configuration template are not conflicting in response to determining that the low-level configuration includes a pointer for the resource indicating that the resource is owned by the particular configuration template.

However, the controller device 10 may be configured to determine that the set of configuration changes to the resource conflicts with the set of owned resources in response to determining that the low-level configuration includes a pointer (e.g., "meta-data": { "src _ uuid": "1234", "src _ type": Firewall Intent ") indicating that the owner of the resource is not a configuration template, and may refrain from applying the set of configuration changes to the resource in response to determining that the set of configuration changes conflicts. For example, the controller device 10 may determine that the set of configuration changes conflicts with the set of owned resources in response to determining that the low-level configuration includes a pointer for the resource that indicates that the resource is owned by the intent-to-generate configuration or another configuration template.

FIG. 5 is a conceptual diagram illustrating an example configuration template 102 and configuration template endpoints 104 as a graph. As shown, vertices used to configure the template 102 to the configuration template endpoints 104 use edges that indicate that the configuration template 102 has configuration template endpoints 104. The vertex of the configuration template endpoint 104 to the referencing element resource 106 (also referred to herein simply as "resource 106") has a ref edge that indicates that the configuration template endpoint 104 references the resource 106.

The configuration template 102 may be defined by YANG. An example YANG extension that defines a "configuration template definition" for a configuration template 102 may include "ext: configure templates ". All of the attributes in the list and container may be attributes defined by the configuration template.

An example YANG extension that defines a "configuration template endpoint definition" for a configuration template endpoint 104 may include "ext: configure template-endpoint ". All attributes in the list and container may be attributes that configure the template endpoint definition. The configuration template endpoint definition may include a "resource-ref" field that specifies an "element resource reference" to the endpoint. In some examples, the configuration template endpoint definition may include a "max-elements" field that specifies a maximum number of endpoints that may be associated with the resource. In some examples, the allowed value of the "maximum element" field may be an integer.

Example pseudo code for an example configuration template definition and a configuration template endpoint definition is as follows.

For example, the configuration template 102 includes a name (e.g., "name") and a description of the configuration template 102 (e.g., "name of service"). As shown, the configuration template 102 may specify a configuration template endpoint 104, the configuration template endpoint 104 including a name (e.g., "name"), a description of the configuration template endpoint 104 (e.g., "name of service"), and a reference element resource 106 (also referred to herein simply as "resource"). Reference element resource 106 may refer to a device resource or any configuration resource within a device.

Resource 106 may be any configuration resource within a device, such as, for example, but not limited to, a Virtual Routing and Forwarding (VRF) instance, a Border Gateway Protocol (BGP) instance, or an Open Shortest Path First (OSPF) instance, or any configuration object on a device. As shown, resources 106 may include, for example, but are not limited to, devices 110, interfaces 112, units 114, areas 116, and/or tags 118. Device 110 may refer to one of elements 14. Interface 112 may refer to a software interface of controller device 10 to element 14. Unit 114 may refer to a logical interface such as, but not limited to, control unit 22, for example. The area 116 may refer to a secure area, which is a collection of one or more network segments that require policy-based regulation of inbound and outbound traffic. The tag 118 may refer to a tag data model that includes a resource selector for identifying sub-resources within a device. Example attributes for configuration templates and configuration template endpoints are presented in table 1.

Table 1

Table 2 shows an example mapping from inputs to the configuration template graph database model.

TABLE 2

In accordance with the techniques described herein, the resource 106 can be part of a configuration template intent model (see, e.g., fig. 7, configuration template intent model 130), and the native configuration can be part of an element native model (see, e.g., fig. 7, element native model 134). As such, the configuration template endpoint 104 may reference the element resource 106 when the configuration template 102 is associated with the configuration template endpoint 104. In this manner, the techniques allow the controller device 10 to verify whether there are any other configuration template instances of the same type that have been associated with any of the element resources 106. If the maximum element is 1, the controller device 10 may only allow one configuration template instance of the same type to be associated with a single resource.

FIG. 6 is a conceptual diagram illustrating an example configuration template system. The intent may be modeled as a graph in the graph model 122, which may be an example of an "opaque intent graph model" for a configuration template. The configuration template service 120 may model the configuration template 102 as an opaque intent in an intent server. An opaque intent data model graphic can refer to a data structure that can transparently represent any model in an intent graphic format. There may be two opaque vertices with a one-to-many association, a configuration template (e.g., configuration template 102) and a configuration template endpoint (e.g., configuration template endpoint 104). The controller device 10 may be configured to apply the schema service 124 to verify the configuration template 102 and the configuration template attributes of the configuration template endpoint 104. In this manner, the controller device 10 may be configured to automatically generate the intent graph model according to the configuration template definition. For example, the controller device 10 may verify the configuration template based on the definitions provided by the configuration template 102 and/or the configuration template endpoint 104. The verification may include mode verification and/or endpoint association verification based on an opaque intent graph model. As used herein, an opaque intent may refer to storing opaque vertices in an intent model, the opaque vertices used to model configuration templates and configuration template endpoints. The endpoint association verification may verify that the configuration template instance does not override another configuration template of the same type.

The controller device 10 may be configured to perform data validation as specified by the following pseudo code.

A configuration template and configuration template-endpoint objects are built from the input.

Validating configuration template attributes with a schema service

For each configuration template endpoint

Validating configuration template endpoint attributes with a schema service

Retrieving resource ref largest elements

If the resource ref maximum element is 1

Retrieving resource 'referent object' of 'configuration template type' from intention DB "

If a referrer exists, it is marked as failed.

For example, the controller device 10 may build the configuration template 102 and the configuration template endpoint 104 from input (e.g., from the administrator 12). In this example, the controller device 10 executes the schema service 124 to verify the configuration template 102 and the configuration template attributes of the configuration template endpoint 104. For example, the controller device 10 may be configured to retrieve the resource 106. In this example, the controller device 10 may be configured to verify whether there are other configuration template instances of the same type associated with any of the element resources 106. If max-elements is 1, the controller device 10 may allow only one instance of the configuration template of the same type to be associated with a single resource. For example, the controller device 10 may determine that the resource is not associated with another configuration template that includes a type corresponding to the type of the configuration template. In this case, in response to determining that the resource is not associated with another configuration template that includes a type corresponding to the type of the configuration template, the controller device 10 may be configured to apply the set of configuration changes specified by the configuration template to the resource.

Fig. 7 is a conceptual diagram illustrating an example data transformation. The configuration template intent data model 130, the element native model 134, the intent data model 140, the abstract configuration model 142, and the element native model 144 may be stored in the configuration database 40 or another database of the controller device 10. Configuration templates intent data model 130 and intent data model 140 may represent examples of intent data model 88 of FIG. 4. For example, configuration template intent data model 130 may represent an example of first configuration template intent 92, while intent data model 140 may represent an example of intent 93. Abstract configuration model 142 may represent an example of abstract configuration model 89 and/or abstract configuration model 90 of fig. 4. For example, abstract configuration model 142 may be an example of abstract configuration 94. The element native model 134 and the element native model 144 may represent examples of the native configuration model 91 of FIG. 4. For example, element native model 134 may include configuration changes to a first set of resources of a device, while element native model 144 may include configuration changes to a second set of resources of the device.

In the example of FIG. 7, configuration template intent data model 130 and intent data model 140 may be stateless intents. Stateless intent may be a fully declarative way of describing the intended network/compute/store state without concern for the current network state. A stateless intent may include, for example, a Virtual Private Network (VPN) connection between two devices. The application workflow may convert the business intent into a stateless intent. An abstract configuration model may refer to a common low-level model of a device. The element native model 134 and the element native model 144 may include one or more instructions of a native language of the device being configured (e.g., element 14).

In the example of fig. 7, the controller device 10 may receive an indication of a stateful intent. For example, the controller device 10 may receive the intent data model 140. In this example, the controller device 10 may determine that there is a status intent. For example, the controller device 10 may determine the abstract configuration model 142. In this example, the controller device 10 may compile the stateless intent into an abstract configuration model. For example, the controller device 10 may compile the abstract configuration model 142 into the component native model 144 based on the device model of the network device being configured. Instead, the controller device 10 may convert the configuration template intent data model 130 directly to the element native model 134 based on the device model of the network device being configured.

As shown in FIG. 7, the configuration changes from the intent generation process 141 and the configuration changes from the configuration template process 131 may be independent. That is, the controller device 10 may be configured to convert the configuration template intent data model 130 into the element native model 134 without determining potential conflicts arising from configuration changes that convert the intent data model 140 into the element native model 144. In this way, the administrator 12 may input a request to the controller device 10 to apply a configuration template that translates to the element native model 134 for applying a set of low-level configuration changes to the elements 14 that conflict with the low-level configuration changes to avoid applying the element native model 144. In such a case, applying the element native model 134 to the element 14 may result in the controller device 10 failing to satisfy the stateless intent of the intent data model 140. For example, when administrator 12 requests a particular bandwidth between

elements

14A and 14D, controller device 10 may not be able to provide the particular bandwidth after applying element native model 134 to element 14.

The techniques described herein may maintain the independence of the intent generation process 131 and the configuration template process 141 while automatically performing validation to help ensure that there are no conflicts between different configuration templates and between configuration templates and intent generation configurations. For example, the element native model 144 may specify a pointer that indicates that the intent data model 140 is the owner of each resource that the element native model 144 is modifying. As such, when the controller device 10 applies the element native model 144 to a resource, the resource may reference a pointer indicating that the intent data model 140 is the owner. For example, the controller device 10 may generate a native configuration for the resource that includes a pointer (e.g., pointer 98, "" meta-data ": [ {" src _ uuid ": 1234", "src _ type": "Firewall Intent" ", etc.) that indicates that the Intent data model 140 is the owner of the resource. In this manner, when the controller device 10 determines that the element native model 134 is to change the resource of the pointer referencing the intent data model 140, the device controller 10 may determine that the set of configuration changes to be applied to the element native model 134 conflicts with the intent data model 140 even though the intent generation process 131 is opaque to the configuration template process 141.

Similarly, the element native model 134 may specify a pointer that indicates that the configuration template intent model 130 is the owner of each resource that the element native model 134 modifies. In this example, when the controller device 10 applies the element native model 134 to a resource, the resource may reference a pointer indicating that the configuration template intent model 130 is the owner. In this manner, when the controller device 10 determines that the element native model 144 is to change a resource that references a pointer to the intent data model 130, the controller device 10 may determine that the set of configuration changes to be applied to the element native model 144 conflicts with the configuration template intent model 130 even though the configuration template process 141 is opaque to the intent generation process 131.

FIG. 8 is a conceptual diagram illustrating example batch association by tag. In the example of fig. 8, configuration template 180 is associated with configuration template endpoint 182. In some examples, the controller device 10 may be configured to apply a batch association. For example, the controller device 10 may be configured to allow the configuration template to apply the tags 184 to the resources for bulk association. A tag may refer to a tag data model that includes a resource selector for identifying a sub-resource. For example, the tag data model may include a resource selector that identifies the phrase "core" in a field of the device. In this way, all Border Gateway Protocols (BGP) starting with the name "core" in the device field may be associated.

In some examples, the controller device 10 may be configured to apply annotation (e.g., annotation) features to the tags 184 of the device management resources. For example, the annotation feature can be used to add arbitrary annotations to the configuration path, as shown in the example configuration below.

In the foregoing configuration, "# core", may represent a resource selector. In this manner, the tags 184 may provide tag definitions, which may include a resource selector that specifies a child resource selection from a configuration. A label data model, such as label 184, may label all BGP beginning with a name in a "core" device. The tag definition may include a resource selector that may specify a child resource selection from the configuration.

The controller device 10 may use a data model that may be YANG or JavaScript Object Notification (JSON). An example of a label definition is as follows.

In the foregoing tag example, "resourceselector" may represent functionality that allows selection of a child resource within a resource. For the "core" tag instance, the resource choices in the tag may be: "/configuration/protocols/mpls/lsp-external-controller [ name ═ nothstar ″. This tag may cause the controller device 10 to select all lsp-external-controllers beginning with "notchstar".

In response to adding the configuration template to the tag, the controller device 10 may be configured to retrieve all resources and associate with the configuration template 180. In response to the dynamic update tag 184, the controller device 10 may be configured to add and/or update associations accordingly. An Element Management System (EMS), such as controller device 10, detects a configuration change, such as when a configuration template 180 is added and/or updated via an intent and/or automation script. In this example, the EMS checks whether the resource matches any of the tags. In this example, the EMS creates and/or updates the configuration template association. That is, the controller device 10 may determine a set of resources, each resource including a respective tag that specifies a particular set of resources, and apply a set of configuration changes to each resource in the set of resources.

Fig. 9 is a conceptual diagram illustrating intent enhancement. The tag data model may include a resource selector for identifying the sub-resources. For example, the controller device 10 may translate the intent into an abstract configuration. The controller device 10 may enhance the configuration with additional configurations. For example, the controller device 10 may create an abstract configuration with a name convention (e.g., a label).

The controller device 10 may determine that it is intended to cause a change to the configuration of the element 14A (202). For example, the controller device 10 may receive the intent generation configuration and determine that the intent generation configuration results in a configuration change to the element 14A. The controller device 10 may generate a low-level model (e.g., native configuration) (204). For example, the controller device 10 may generate a low-level model from an abstract configuration model generated by the controller device 10 using an intent data model.

The controller device 10 may notify the tagging infrastructure of the resource (206) and determine that the tag definition matches the resource (208). For example, the controller device 10 may create an abstract configuration with a name and create tags for the device and resource selectors using matching criteria. The controller device 10 may determine one or more configuration templates associated with the tags (210) and add the resource association to the configuration templates (212). For example, the controller device 10 may detect an added resource and add and/or update a tag association for the new resource. In this way, the controller device 10 may be configured to apply bulk associations to a plurality of resources.

In accordance with the techniques described herein, the controller device 10 may be configured to support a programming approach that models configuration templates in a network. The controller device 10 may also be configured to perform model validation. The controller device 10 may be configured to allocate configuration templates on arbitrary resources. Examples of a resource may include, for example, a device, a port, a region, a VLAN, a routing instance, a configuration resource object, or another resource. The resources may or may not be managed by the controller. For example, the controller device 10 may manage the resources, or the resources may be any path in the configuration that exists directly on the device.

In some examples, the controller device 10 may be configured to support configuration templates with the intent. For example, the controller device 10 may be configured to prevent the configuration template from overriding the intent generation configuration. In some examples, the controller device 10 may be configured to detect conflicts across configuration templates, intents, and/or OOB changes. In some examples, the controller device 10 may be configured to enhance the configuration by configuring the template. In some examples, the controller device 10 may be configured to associate the configuration template using the resource tag. In some examples, the controller device 10 may be configured to modify resources in the controller device 10, or may retrieve resources directly from a device database as needed. The controller device 10 may be configured to mark resources on the device.

FIG. 10 is a flow diagram illustrating an example process for managing network devices using a combination of configuration templates and intents. For data structures, the controller device 10 may receive a configuration template specifying a set of configuration changes to be applied to a resource of a plurality of resources of a plurality of network devices. The data structure may include a plurality of nodes, each node of the plurality of nodes representing a respective network device of the plurality of network devices, and a plurality of edges defining relationships between the plurality of nodes. The low-level configuration of each respective owned resource in the set of owned resources for the plurality of resources may include a pointer indicating an owner of the respective owned resource. In response to determining that the low-level configuration of the resource does not include a pointer indicating that the owner of the resource is not a configuration template, the controller device 10 may determine that the set of configuration changes does not conflict with the set of owned resources (304). In response to determining that the set of configuration changes does not conflict with the set of owned resources, the controller device 10 may apply the set of configuration changes to the resources.

The techniques described in this 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 circuitry, as well as any combinations of such components. The term "processor" or "processing circuitry" may generally refer to any of the preceding logic circuitry, alone or in combination with other logic circuitry or any other equivalent circuitry. The control unit, including hardware, may also perform one or more techniques of this disclosure.

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 of the described units, modules or components may be implemented together or separately as discrete but interoperable logic devices. Depiction of 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 realized by separate hardware or software components. Rather, functionality associated with one or more modules or units may be performed by separate hardware or software components, or may be integrated within common or separate hardware or software components.

The techniques described in this disclosure may also be embodied or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable medium may cause a programmable processor or other processor, for example, to perform the method when executing the instructions. Computer readable media may include non-transitory computer readable storage media and transitory communication media. The tangible, non-transitory, computer-readable storage medium may include Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory, a hard disk, a CD-ROM, a floppy disk, a cassette, magnetic media, optical media, or other computer-readable storage media. The term "computer-readable storage medium" refers to physical storage media rather than signal, carrier, or other transitory media.

Claims

1. A method, comprising:

receiving, by a controller device that manages a plurality of network devices, a configuration template that specifies a set of configuration changes to be applied to a resource of a plurality of resources of the plurality of network devices, and for a data structure that includes a plurality of nodes and a plurality of edges, each node of the plurality of nodes representing a respective network device of the plurality of network devices and the plurality of edges defining relationships between the plurality of nodes, wherein a low-level configuration of each respective owned resource of a set of owned resources of the plurality of resources includes a pointer that indicates an owner of the respective owned resource;

determining, by the controller device, that the set of configuration changes to be applied to the resource does not conflict with the set of owned resources in response to determining that the low-level configuration for the resource does not include a pointer indicating that the owner of the resource is not the configuration template; and

applying, by the controller device, the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources.

2. The method of claim 1, wherein determining that the set of configuration changes does not conflict with the set of owned resources comprises: determining that the low-level configuration for the resource does not include the pointer indicating the owner of the resource.

3. The method of claim 1, wherein determining that the set of configuration changes does not conflict with the set of owned resources comprises: determining the low-level configuration for the resource includes the pointer indicating the owner of the resource and the pointer indicates that the owner is the configuration template.

4. The method of claim 1, further comprising:

determining, by the controller device, that the set of configuration changes conflicts with the set of owned resources in response to determining that the low-level configuration for the resource includes the pointer indicating that the owner of the resource is not the configuration template; and

refraining, by a controller device, from applying the set of configuration changes to the resource in response to determining that the set of configuration changes conflicts with the set of owned resources.

5. The method of claim 1, further comprising:

generating, by the controller device, a configuration based on the intent, applying a set of configuration changes to the owned resources in the set of owned resources; and

modifying, by the controller, the data structure to include the pointer indicating the owner of the owning resource to point to the intent generation configuration.

6. The method of claim 1, further comprising:

receiving, by the controller device, an indication of a stateful intent;

determining, by the controller device, a stateless intent to implement the stateful intent; and

compiling, by the controller device, the stateless intent into the intent generation configuration.

7. The method of claim 1, wherein the configuration template is a first configuration template, the method further comprising:

applying, by the controller device, a set of configuration changes to an owned resource of the set of owned resources based on a second configuration template; and

modifying, by the controller, the data structure to include the pointer indicating the owner of the owning resource to point to the second configuration template.

8. The method of claim 1, wherein the data structure indicates that the resource includes a tag data model that includes a resource selector that specifies a particular resource group, the method further comprising:

determining, by the controller, a set of resources of the plurality of resources, each resource of the set of resources including a respective tag that specifies the particular set of resources; and

applying, by the controller device, the set of configuration changes to each resource in the set of resources.

9. The method of claim 1, further comprising:

determining, by the controller device based on the intent generation configuration, a set of configuration changes to be applied to an owned resource of the set of owned resources, the owned resource including a tag specifying a particular resource group;

determining, by the controller, one or more owned resources of the set of owned resources, the one or more owned resources including a tag that specifies the particular set of resources; and

applying, by the controller device, the set of configuration changes to each of the one or more owned resources.

10. The method of claim 1, wherein the resource comprises a device, a port, a region, a virtual local area network, a routing instance, or a configuration resource object.

11. The method of claim 1, wherein the configuration template comprises a configuration template graphical database model that specifies configuration template vertices and configuration template endpoint vertices.

12. The method of claim 1, wherein the configuration template is associated with a configuration template endpoint, and wherein the configuration template endpoint includes a reference to the resource, and wherein applying the set of configuration changes to the resource is in response to determining that the resource is not associated with another configuration template that includes a type corresponding to a type of the configuration template.

13. The method of claims 1 to 12, further comprising:

verifying, by the controller device, the configuration template; and

enhancing, by the controller device, the configuration of the resource with one or more additional configurations.

14. A controller device that manages a plurality of network devices, the controller device comprising one or more processing units implemented in circuitry and configured to:

receiving a configuration template for a data structure, the configuration template specifying a set of configuration changes to be applied to a resource of a plurality of resources of the plurality of network devices, the data structure comprising a plurality of nodes and a plurality of edges, each node of the plurality of nodes representing a respective network device of the plurality of network devices and the plurality of edges defining relationships between the plurality of nodes, wherein a low-level configuration of each respective owned resource of a set of owned resources of the plurality of resources includes a pointer indicating an owner of the respective owned resource;

determining that the set of configuration changes does not conflict with the set of owned resources in response to determining that the low-level configuration for the resource does not include a pointer indicating that the owner of the resource is not the configuration template; and

applying the set of configuration changes to the resource in response to determining that the set of configuration changes does not conflict with the set of owned resources.

15. The controller device of claim 14, wherein to determine that the set of configuration changes does not conflict with the set of owned resources, the one or more processing units are configured to determine that the low-level configuration for the resource does not include the pointer indicating the owner of the resource.

16. The controller device of claim 14, wherein to determine that the set of configuration changes does not conflict with the set of owned resources, the one or more processing units are configured to determine that the low-level configuration for the resource includes the pointer indicating the owner of the resource, and the pointer indicates that the owner is the configuration template.

17. The controller device of claim 14, wherein the one or more processing units are configured to:

determining that the set of configuration changes conflicts with the set of owned resources in response to determining that the low-level configuration for the resource comprises the pointer indicating the owner for the resource is not the configuration template; and

refraining from applying the set of configuration changes to the resource in response to determining that the set of configuration changes conflicts with the set of owned resources.

18. The controller device of claim 14, wherein the one or more processing units are configured to:

generating a configuration based on the intent, applying a set of configuration changes to the owned resources in the set of owned resources; and

modifying the data structure to include the pointer indicating the owner of the owning resource to point to the intent generation configuration.

19. The controller device of claims 14-18, wherein the one or more processing units are configured to:

receiving an indication of a stateful intent;

determining a stateless intent to implement the stateful intent; and

compiling the stateless intent into the intent generation configuration.

20. A computer-readable storage medium encoded with instructions for causing one or more programmable processors to perform the method of any of claims 1-13.