Use Cases for Intent-Based Networking

December 6, 2017 Alan Sardella

This is Part II of a Two-Part Series; in Part I we discussed the components and attributes of intent-based networking. Here, we’ll detail several use cases in the areas of traffic management and threat mitigation for intent-based networking.

Thanks to Extreme Networks' Product Managers for 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.

Having established the key components of an intent-based networking system, let’s take a look at some examples of how this approach to networking bears fruit. For each of the services we’ll discuss here, there is generally an associated SLA that must be met.

The integrity of that SLA may be measured by your internal operations, another department within your enterprise, or by a customer. The classes of use cases we will examine are:

  • Traffic Management
  • External Risk Mitigation
  • Network Security Hardening

Traffic Management 

The way traffic management is handled today (Figure 1), sensors on individual network elements (streetlights or switches) send information to a local central office (CO), which backhauls it to a data center (DC).

 

Figure 1: Traffic Management Today (for Streets or Networks)  

This monitoring data is shipped to a NOC, where it is examined and analyzed. The analysis of the data is dependent on the skill set of the personnel at the NOC at that instant of time.

This is a time consuming step, taking anywhere between a few seconds to a few hours, and at times even a few days. Perhaps there is a problem, or maybe (if it’s not an outright critical issue) a small configuration change can help things run more smoothly.

If it’s determined that changes should be made, tickets are opened in the NOC and sent to a team of engineers working in (typically) a different office—either headquarters or a support center. That team determines a corrective action, and sends configuration changes to network elements in the DC, the CO, or perhaps (continuing the “street traffic” analogy) to the “traffic light” (or access point).

However, by this time, the underlying state of the traffic (network or street) may have changed, and the configuration update may have less than the desired effect.

The transportation analogy implied by Figure 1 is very apt here, for you can see that when the changes are not in real time, the remedial action, though correct, is inconsequential or ineffective: changes in the traffic light pattern a couple of hours later will still leave you stuck in the intersection for the interim.

In the pure networking context, examples of why the configuration change might be different based on the state include various anomalies such as:

Now let’s look at network traffic management in the world of intent-based networking (Figure 2).

 

Figure 2: Traffic Management with Intent Based Automation

There is still backhaul to the DC, yet with service assurance and data collection modules in place, the situation is rapidly assessed based on the data collected, and plans are made based on multi-dimensional attributes (time, place, traffic density) for reconfiguration commands based on the state of the network (or roadways in this pun-filled example).

The service delivery module sends the appropriate to the data center in near-real time, so that when the change is made, it fulfills the intent and also provides the corrective action that is appropriate to the underlying state of the network.

External Risk Mitigation

For an example of external risk mitigation, consider Figure 3. An intruder seeks access to highly classified data.

 

Figure 3: External Risk Mitigation

Here, there are a variety of network slices running on the infrastructure:

  • A civilian (unclassified) network
  • A classified network
  • A top-secret (FYEO: for your eyes only) network
  • A management network

If the intruder forces entry into a facility to gain access to the top-secret (FYEO) network, an external risk alarm is sent to the service assurance module. Since all the facilities and networks are being continuously monitored, the service assurance module determines that the FYEO network needs to be taken offline in the facility that has been compromised. 

The service delivery module takes the corrective action on both the compromised facility and the one that needs to now be the border of the FYEO network. The data is now safe.

Related examples could include unauthorized access to corporate assets (such as servers, storage, or the network) either during or after business hours. If this occurs, affected network partitions can quickly be isolated or shut down. 

Network Security Hardening

In Figure 4, we see an example of network security hardening. In this case, perhaps there is an Internet of Things (IoT)application such as a smart home.

Figure 4: Network Security Hardening

The collection of homes is forming a fog network. The fog end-nodes (inside a home) are more susceptible to a botnet attack, and service providers are less able to enforce security on the end-nodes, leaving the entire service provider network vulnerable.  Visibility-aware network elements on this fog network can detect a DDoS attack.

The data collection (monitoring) module, in conjunction with the service assurance module, will:

  • Take the action to assess the situation and plan what to do
  • Order the service delivery engine to reconfigure relevant equipment in the DC and in the CO

Traffic can be scrubbed and/or black holed. If this is done in time, the effect of the attack will be at most limited to one CO and the rest of network is unaffected.

The value of this confining an attack of this sort can be seen when you consider the massive 2016 DDoS attack that brought down many web sites worldwide.  With this self-healing technology in place, the damage from such an attack is reduced by many orders of magnitude.

If you’d like to learn more about the Extreme Networks products that are discussed in this article, please view these resources:

Please reach out to your Extreme Networks sales representative for more information on any of our solutions. 

Read Components of Intent-Based Networking, Part I, of this series here!

The post Use Cases for Intent-Based Networking appeared first on Brocade.

About the Author

Alan Sardella

Alan Sardella is a Product Marketing Director at Extreme Networks, responsible for data center and cloud solutions including automation, telemetry and infrastructure. Alan has been in the networking industry for 15 years, working for a variety of vendors and open source providers, and focusing on routing, switching, and software-defined networking solutions. He worked in software development and technical training prior to that, and his academic training is in both computer science and the humanities.

More Content by Alan Sardella
Previous Article
Towards Machine Learning in Networking: Benefits Begin Now
Towards Machine Learning in Networking: Benefits Begin Now

Machine Learning (ML) has major applicability in IT automation, turning relevant data into actionable softw...

Next Article
Components of Intent-Based Networking
Components of Intent-Based Networking

Intent-based resource management is the ability of an automation system to interpret the intent of the user...