Data Center

Components of Intent-Based Networking

by asardell ‎05-20-2017 09:45 AM - edited ‎05-24-2017 05:07 PM (2,729 Views)

This is Part I of a Two-Part Series, where we discuss the components and attributes of intent-based networking, including the capabilities for visibility, monitoring, and programmability from the Infrastucture. In Part II, we’ll detail several use cases for intent-based networking.

 

Thanks to Brocade Product Managers for providing the core concepts in this article. The material was presented by Ravi Rao at a Silicon Valley Technology Innovation and Entrepreneurship Forum Held at Stanford University this past May 6.

 

A couple of weeks ago, we explored how the movement towards intent-based networking grows from the business reasons for making demands of IT.  Here, we’ll go into a bit more detail on the components of an intent-based system and provide some use cases.

 

Intent-based resource management is the ability of an automation system to interpret the intent of the user and deliver the service to match that intent. In IT terms, if a user specifies an SLA for a resource, the automation system must include the following abilities:

 

  • Deliver the resource (network) to suit the SLA
  • On a continuous real time basis, monitor the service against the SLA
  • If and when the service falls out of compliance, take remedial action to restore compliance.

 

The ability to react quickly and decisively to a given situation is only possible when we implement a so-called MAPE-K loop as shown in Figure 1.

 

mape-k.gif

 

Figure 1: Monitor, Analyze, Plan and Execute using Knowledge (Source: IBM

 

The expression MAPE-K stands for Monitor, Analyze, Plan and Execute using Knowledge. As Figure 1 shows, there are sensors to handle events and collect data, and there are effectors to “effect change” (program) the underlying managed resources.

 

When implementing intent-based networking, monitoring or visibility into the existing infrastructure become paramount. Information needs to available at all layers to assess and plan the right action. In order to make automation of the process successful, the monitoring or visibility of the process also has to be rightly available.

 

The industry has embraced open cloud management platforms and DevOps tools to add workflows for automation. But we need to bring this same level of programmability all the way down to switches, routers and the ASICs to ensure consistent flexibility from top to bottom of the data center network stack.

 

As you bring agility throughout the network stack, you also need to ensure integration with other organizational technology domains such as compute, applications, and operations. This is where the cross-domain workflow comes into play. The network needs to be part of the technology toolchain but also integrated with the overall culture and skillsets of the organization, including people, process and policy.

 

Infrastructure Attributes

 

Of course, most network infrastructure can be programmed by driving their command line interfaces through scripts. But forward-looking hardware also includes built-in capabilities for supporting visibility.

 

In order for intent-based infrastructure to be successful, the network itself should have some inherent characteristics that can support a truly intelligent system. If we start from the bottom, the key requirements are shown in Figure 2. Infra Designed Built for Automation1.png

 

 

 

Figure 2: Infrastructure Designed and Built for Automation

 

The infrastructure should provide the following capabilities:

 

 

Essentially, the infrastructure of an intent-based network must be able to answer the many questions we may ask of it. It should provide knowledge bases for making the data center network a business platform that fulfills business policy and intent while always verifying changes against network state.

 

The Automation Framework

 

Figure 3 shows how Intent based automation will ensure that the network will perform as per the intent. The elements of the loop are labelled in the diagram. 

 

Auto Framework1.png

Figure 3: Logical Architecture for Self-Healing Automation Framework
 
The key components are as follows:

 

  • Data Collectors will perform the monitor function after the service has been delivered. A collector will monitor and publish the data
  • Service Assurance will perform analysis based on the operational policies (and intentions) of the enterprise or data center; if there is noncompliance, then remedial action will be undertaken
  • Service Delivery will perform the remedial action just as it performed the action of creating the new service

 

The service assurance function is the most critical component. This is where the autonomic system uses the visibility capabilities in order to fulfill use cases such as auto-remediation, application debugging, ensuring proper scale of an application or infrastructure, or mitigating threats.

 

Figure 3 also illustrates the great dividends that are paid by combining intent with automation and visibility. Effectively, there is an exponential gain in agility, high availability, and network efficiency.

 

Call to Action

 

Brocade products that are relevant to this vision are linked in the article:

 

In Part II of this series, we’ll detail some use cases that fulfill intent-based networking in the areas of traffic management, external risk mitigation and network security hardening. Stay tuned.

 

And a quick head-up: We’ll be hosting at the Beer and Gear of NANOG 70 and can discuss these solutions to map them to your own use cases.

 

 

 

 

Top Kudoed Posts