Step 1: Identify Network Intents

One of the tasks of phase three was to identify which networks, applications, and services are deployed on the campus network. These networks, applications, and services have been translated into virtual networks or templates that were used to provision and deliver those same services.

Use that list of networks, applications, and services to create a full inventory of possible network Intents (including each individual requirement). Extend this inventory with required application policies, security policies, and other requirements as well. The primary focus should be the campus network, but if specific datacenter or WAN requirements come up, they should be registered in the inventory too. Although an inventory has already been made, it is not uncommon in enterprises that the specific requirements for application policies, such as Internet access and bandwidth requirements, are not known. Therefore, this task can take quite some time and could require support from the stakeholders to get this information available. The obtained information is paramount in order to move forward to the next step.

Step 2: Generalize Network Intents

Now that a full, extensive list of networks, services, applications, security policy, application policies, and requirements is created, this list should be validated against the business departments to verify it matches their needs (first step to business intent-driven services). Once the validation has occurred, use the list to define a set of generic services that can be used to implement all items on this list, including all restrictions, policies, and requirements.

This list of generic services should be set up in such a way that applicable restrictions, policies, and requirements can be defined using a structured description.

This generalization is similar to the creation of templates in phase three, except that this is one step further, and variables are replaced with generic constructs, structures, and abstractions. The ultimate goal would be to restrict the list of services to levels of network, network service, and application.

An example could be that for an organization, three logical, separate networks are required: one for security devices, one for employees, and one for guests and employeeowned devices. Although the services are different, they all share that they are based on a common virtual network and IP addressing. To generalize these three Intents, a single generic service called “virtual network” could be defined, with restrictions (for example, the maximum number of virtual networks to be deployed), policies (access rules), and requirements (IP address settings and DHCP server settings). Based on that generalization, it must be possible for each individual network to be defined and implemented.

Once this generic list of services is created, validate that all applications and possible new applications or networks can be defined with them as well.

Step 3: Define Concept API Definitions

In general API methodology, it is common to have a minimal set of API calls for the Creation, Reporting, Update, and Deletion (CRUD) of an information element or service. Combine this methodology and the list from step 2, “Generalize network Intents,” to create a list of concept API definitions. These API definitions should have a description and structures for input and output that reflect the minimal list of services from the previous task. Table 10-1 provides an example of such concept API definitions for a network Intent. In this case the API definition is based on REST-full APIs.

The table allows for creating, deleting, and searching for virtual networks. Some variables or structures are optional and end with a ? while others are required. The first example in the table defines an API call named newNetwork. This method creates a new virtual network and uses a number of input parameters, such as nrClients. This parameter reflects the number of clients that connect to the network, which is used as a number to request the IPAM service within the network for the appropriate IP network size. The API call deleteNetwork is used to delete a virtual network, either immediately or at a scheduled date or time.

These API definitions form the basis of APIs, which can be used by business intents to request network services from the campus network.

Step 4: Match API Calls Against Tool

A network that is designed around Cisco DNA can have one or more tools that allow for the provisioning of services onto the campus network. Cisco DNA Center is a great example of a tool that allows for the creation and deployment of a virtual network or a specific application policy. But Cisco DNA Center is intended for the enterprise part of the campus network. The security policies for the campus network can be defined within Cisco DNA Center (for SDA deployments) but are effectively configured on the central policy server (Cisco ISE). Similarly, an Internet access policy is configured via FirePower management or via vManage in the case of an integrated SD-WAN solution. Each of these tools has the possibility to be enabled to use APIs.

To recap, multiple tools can reside in the Cloud Service Management building block and can be used for different purposes.

In this task, the concept APIs from the previous step are compared with the available APIs of the network tools that are used within the organization. Append the earlier table with the name of the tool, the API call, and the API definition that will be used to define that generic service.

If a concept API definition is not implemented with one of the known tools, research whether multiple API calls or alternatives exist for that concept API definition. Document these API calls in the same list.

At the end of this step, the concept list from step 3 is extended with a list of existing APIs from the tools used by the campus network team.

Step 5: Create Network Intents Service Catalog

Based on the previous steps, a service catalog can be created for all network intents (network, service, and applications) that can be provided on the campus network. This service catalog essentially describes the technical services the campus network can deliver, including descriptions of how to request those services automatically using APIs. This service catalog not only contains a name and a description but also a list of API calls that are required to be executed by a software developer in case the intent needs to be requested via APIs.

If some services require manual configuration, this should be registered in the service catalog as well. (These are the gaps described in the previous step.) These services can still be provided by the network team, but take a longer time to deploy (traditional deployments).

This last step is used to create such a service catalog. See Table 10-2 for an example network intents service catalog. This service catalog represents confirmed definitions for the services that the organization is capable of running on the campus network. It effectively represents the northbound services and APIs available for the Intent-Based Network created with the previous phases.

Communication Plan

Although the network has become an essential part of all business processes within the enterprise, it has also become so reliable and predictive that it is essentially invisible. Business departments view the network as a common facility like electricity or restrooms. For IBN to be successfully implemented within the business departments, they need to be aware that the network is actually performing some fairly complex tasks to bring resilient, reliable, and predictable connectivity services to that business department. The department also needs to become aware that it will experience a standstill if connectivity is not available.

The preceding use case was of course a big compliment for LogiServ and the transition. But intrinsic to that compliment was also the notion that the unit manager was not aware of what LogiServ actually did or was doing to operate that environment so successfully. This situation is often the case in networking. No employee or manager will give a compliment when the network operates without issues, but each will raise major incidents if there is a possible network issue.

A communication plan must be composed. This communication plan will be used internally to make the network more visible and to raise awareness to the importance of networks, connectivity, and the risks of no or limited security. The plan also covers opportunities and chances that an Intent-enabled network creates for the business.

The plan is similar to a marketing plan. Any knowledge and intelligence on marketing and communication should be leveraged, all related to the type of enterprise and its culture. Some enterprises might benefit from a large communication while others might benefit from smaller steps. Leverage the marketing knowledge internally or externally and emphasize the importance of the network.

Understand the Business

This is an often underestimated part of any IT-related project. Of course, employees from other business departments know what a computer is, but they do not know what a network is. Similarly, IT employees know the concept of a warehouse management system but might not know the importance to the business of a specific script once created.

It is recommended to talk with several employees in the different business departments and ask questions on what they do, how they do their job, and how IT can support them.

Understanding a business only brings benefits to IT, as IT starts to understand what drives the business, and only then can it truly support the business with the right technology.

The communication plan can also leverage knowledge gained from this step to share what kind of impact the network has on a specific process and how that was solved.

Set Up Pilots or Proof of Concepts

The communication plan and understanding the business help to identify pilot projects to create quick wins. Find out which business departments face certain issues or challenges that can easily leverage the capabilities of an Intent-Based Network. These business departments should be willing to test, use new technology, and accept failure in pilots as well. In other words, these business departments are usually at the front of the technology adoption curve.

The pilot is used not only to demonstrate that using APIs and the service catalog supports the business process but also for the network operations team to gain trust and experience in the fact that APIs can automatically request and remove applications on the network.

Build Apps/Portals to Support the Business

Once pilots are successful, use those pilots to build applications or portals that can be managed and operated in a production grade system. Also if small additions to a portal can bring great benefit to the enterprise, this should be a chance to show and demonstrate the power of IBN and the service catalog. An example could be the integration between Cisco ISE and the guest registration portal for the front desk security. An employee would then only register guests via the front desk security portal, while in the background the necessary guest credentials are created automatically for the registered guests.

Share Successes and Failures

An integral part of bringing the service catalog to the enterprise and using the communication plan is to share. Share the success stories of pilots and changes that were made because of IBN. But also share failures, mistakes, and lessons learned. Share the success after applying the lessons learned from a failure; it shows that the IT department is human.

These recommendations are intertwined with each other and run sequentially as well. That makes the execution of these steps perhaps rather difficult, and specialists in communication and marketing can be of great support in this task. The end goal for this task is twofold: raising awareness of the network and having a number of business departments or processes leveraging the Intent APIs for their network services. This is the only way to integrate IBN into the enterprise: by continuously sharing, communicating, and integrating with the enterprise.

Response to Security Incidents

Network security has become increasingly important to most enterprises. The impact of ransomware, malware, and other malicious intent can have drastic consequences for the functioning of the enterprise.

Security operations can benefit from an Intent-Based Network as well. When an indication of compromise (IoC) of an endpoint is seen on the network, a manual intervention needs to be executed to have that endpoint isolated (quarantined), investigated, or ignored. This requires close cooperation between security and network because these types of operations are commonly executed by two different teams.

With Intent-Based Networking, an IoC can trigger a push notification to an iPhone, just like a new text message is received. The security operator (for example, during night hours) can look at the IoC message and swipe to the left. The operator can then select quarantine, investigate, or ignore. Once the intent is known, the network is automatically configured for the intent for that specific endpoint, and the central policy server is used to trigger a change of authorization to effectuate that intent. There is of course reporting and communications between the two teams, but the incident itself can now be handled accordingly.

Organizing a Meeting

At larger enterprises the organization of a meeting with both internal employees and guests can take almost a day. Besides finding the date, an agenda needs to be set up, topics need to be prepared, and other non-content-driven activities must be executed, such as sending out invites, registering the guests and employees at security, organizing a meeting room, changing that room because more people join than expected, organizing the videoconference unit, organizing lunch, and managing Internet access for guests.

In summary, quite a lot of tasks are commonly manually executed using different systems. Most enterprises have a portal where you can register visitors in advance. Another portal would be used for creating guest access, and yet another portal to communicate with facilities for the meeting room and organize lunch.

With IBN and portals leveraging APIs, a lot of these tasks can be executed more easily, resulting in the following use case.

A user, organizing a conference, logs in to the facility’s portal and checks for a room for a specific date, start time, and end time. The user selects the room and moves to the next screen. In that screen the user is able to register all employees and visitors for that meeting, upload an agenda, and select the checkboxes for lunch and Internet access. Once the room reservation is committed, the system creates a conference for the user and keeps it in pending. The system will send out invites with the agenda to the registered delegates, allowing them to register and confirm.

Three days before the event starts, the system will send out a notification to facilities to register for a lunch. The system also registers the visitors, on behalf of the host, with security. One day before the event starts, the system will connect to the Internet guest system and register guest accounts for the visitors who have confirmed the meeting. The Internet guest system will send out emails to the visitors with information on how to connect to the network.

One hour before the meeting starts, the system will ask the network to create a wireless network and associate the registered (and confirmed) employees as well as the visitors to that temporary network.

The network is now prepared for the conference, and within that conference that network can be used by the delegates to collaborate and share data and screens and be more productive.

Two hours after the meeting ends, the system will request the network to remove the temporary wireless network and its policies and to disable access for guest users.

This workflow or use case already exists in one form or the other. Several systems already provide parts of the solution, and these systems have APIs available. It is only a matter of defining a new portal and leveraging the APIs; all aspects are tied into a single workflow that makes the life of a host easier. It is even possible to build a mobile phone app that leverages the same APIs as the portal, so that the host can organize the event from his or her phone, using an enterprise-built app. Essentially, the business intent of the host is transformed into several actions, and some of them are deployed in the network and removed from operation when required.

Authorized Access

This use case is perhaps a bit more futuristic, but with the power of IBN (and enabling end-to-end Intent up to the datacenter) it is quite possible.

An employee would like to get access to a specific application—for example, a drawing application—because he or she needs to create a specific type of drawing for a project or a customer. The employee logs in to the self-service portal or app and selects the drawing application. Because the employee has enough App-Credits available, the request is automatically approved and added to the list of used applications for the license account report.

As the application request is approved, provisioning methods push the application toward all the employee’s devices, including workstations, virtual desktop, and tablet. The network and infrastructure policies are updated so the employee now has access to the drawing application and the required shared data. The application itself is, via a policy, also allowed access to the user’s directory to save data. Mobile endpoints are configured with the appropriate tunnels and policies to make the application accessible from anywhere.

The employee can now use the drawing application and creates a drawing or design.

When finished with the application, the employee will deregister the drawing application from her inventory. Once that is committed, the policies applied are removed, access to data is retracted, and the application is removed from the different devices.

The intent of the employee is to have access to a drawing application for a businessspecific reason. The network and infrastructure are programmable, and the employee can be serviced automatically. APIs are used throughout the process to facilitate this intent.

Commonly, these types of workflows would require an approval and formal change requests on several aspects. But because the resulting components of the intent (pushing an application, setting up access policies) have been tested before, the APIs can be leveraged to execute this kind of workflow automatically without approval and deliver much faster.

With the programmability of the network, the number of use cases is almost unlimited, and many more use cases can be defined, described, or implemented. Some of these use cases have already been developed or will be developed over time. It is meant to provide insight into the power and possibilities that can be enabled now that the enterprise is Intent-enabled.