An Open Approach to Implementing Intent-Based Networking

Pica8’s PICOS® network operating system and AmpCon automation framework offer a viable open IBN solution for the whole enterprise – from data center to the access edge.

Introduction: IBN Comes of Age

While the concept of intent-based networking has been with us for some time now, we’re only now starting to see actual implementations. But given many of the underlying technologies are now mature, researchers expect the uptake to be rapid.

A report by Research and Markets predicts more than 70% of enterprise companies will implement intent-based networking in some form by 2025, by which point the global market for IBN will exceed $5 billion.

For most enterprise organizations, IBN is coming of age at just the right time. More and more devices are demanding entry at the network edge while private cloud data centers are proliferating and growing ever-larger. IBN promises to help by dramatically streamlining network operations, enabling fewer staff to manage larger networks by automating many tasks. In turn, organizations stand to benefit from not having to find and retain as many experienced – and scarce – network managers.

Intent-based networks automate numerous aspects of network operations. Instead of manually configuring devices, automation takes on that role, and IBN can capture the business intent behind various applications and translate it into policies that can be automatically applied to network devices in order to achieve desired outcomes. The idea is to automate the process of ensuring each application meets its pre-defined level of network performance and availability characteristics.

In that respect, IBN is in many ways the logical evolution of software-define networks, where network operators define policies in a central controller that are then applied across the network. Open, controllerless IBN takes that a step further by automating the policy development on the fly to meet predefined business requirements.


Organizations do have a decision to make on how to implement IBN, however. The choices come down to going with a legacy vendor’s implementation, such as Cisco Digital Network Architecture (DNA), or implementing an open, standards-based approach.

Pica8, for example, is offering a path to IBN based on its open network operating system, PICOS, that runs on white or brite box network switches. PICOS pairs with Pica8’s open, controllerless AmpCon automation software to handle everything from network device deployment and configuration to policy implementation and control. This is the heavy lifting part of IBN – activation – meaning the configuration of systems and the orchestration of policies, which is an excellent starting point for an IBN implementation. (It’s important to note AmpCon does not have to take full control of any switch in a network and can also work harmoniously with any other management and policy tools an enterprise may be using.)

Pica8 firmly believes organizations should have choice in the vendors they use in their enterprise networks. Its open approach to IBN provides that choice, while also enabling users to employ many open tools their organization is likely already using, such as the Ansible automation platform favored by many DevOps and systems management groups.

In this paper, we’ll go through the key components of an open IBN platform, the benefits it brings, as well as Pica8’s specific approach.

Four Key Open IBN Components

The four crucial components to an open IBN deployment are:

  • Monitoring and telemetry data collection
  • An automated event handling engine
  • A centralized network management platform
  • An open network architecture to enable advanced software capabilities


Effectively implementing IBN requires the constant monitoring of network traffic, so you can ensure each application is getting the type of performance it requires and detect any security events.

An open approach to network monitoring is to use open protocols, such as gNMI–gRPC, both developed by Google. gNMI is a network management protocol that provides the ability to retrieve operational data on the state of network devices via streaming telemetry or snapshots. It also supports remote network device configuration installation and manipulation.

gNMI is built on the open source gRPC remote procedure call framework. It uses HTTP/2 as its transport layer and features bidirectional streams, server push support, load balancing, application-level flow control and more. gRPC is an open source project that’s under active development, so users can expect continued improvements.

Data collected via gNMI-gRPC can be exported to a big data platform, such as an ELK cluster (for ElasticSearch, Logstsh, Kafka), where it can be analyzed to detect performance and security issues. This is a far more efficient approach than having a controller or network management system extract SFLOW data from network devices.


With the network event data in hand, the next step is having a centralized network controller than can enforce policies in response to events. The controller is entirely software-driven, acting in real time to enforce policies and ensure service level agreements are met. In that sense, it automates everyday network management functions, enabling organizations to reduce the number of network administrators required to monitor and act upon alerts.


A centralized network management platform gives network administrators an overall view of the network. Whereas they used to manage individual switches and routers, now they manage the network as a whole. The platform gives them a view into how the network is functioning and supports features including change control functions and policy development. Administrators also use the console to manage the various abstracted network features and elements.


Only an open network architecture can ensure the ability to collect network telemetry data from all networked devices and platforms without vendor limitations.

An open architecture also enables the gradual addition of IBN elements, which is important because no company is going to implement IBN wholesale overnight. Embracing an open approach enables companies to inject modern automation and software practices into the network when and where they make sense, enabling a gradual rollout.

With this open approach, there’s no reliance on a single legacy vendor for all IBN components, with the resulting vendor lock-in and, most assuredly, increased prices. Organizations can instead follow a backwards-compatible, best-of-breed approach that enables them to select the most appropriate network hardware and software for each requirement, whether it’s the data center network, campus or edge, all with a common management interface. An open network architecture has the additional advantage of letting enterprises differentiate from their market competitors, rather than each company fielding the exact same cookie-cutter network capabilities.

Benefits of Open Intent-based Networking

An open approach to intent-based networking provides numerous cost and operational benefits to enterprises and other organizations.


As noted earlier, open IBN dramatically reduces the time dedicated to network operations. Automated, policy-based responses to network events means network administrators and managers no longer have to spend hours staring at monitoring screens, or responding to alerts sent by text or email. Instead, the network responds on its own, always taking steps to ensure the business intent behind each policy is followed.

This can dramatically reduce operations costs, enabling companies to free up experienced network staff from “keeping the lights on” so they can take on more strategic work – an important point given many companies are now in the throes of digital transformation efforts that require network expertise.


An open IBN approach also ensures each application gets the performance it requires and that SLAs are consistently met. Network reliability and uptime increase because humans are largely taken out of the equation in terms of responding to network events, so they are resolved more quickly.


Enterprises can use their choice of vendor with an open approach to IBN, rather than relying on a single vendor to deliver all hardware components. Enterprises can now deploy open, white/brite box network switches throughout the network, from the data center to the campus and out to the access edge, and have the entire enterprise be managed as a single network. Such a strategy enables organizations to consistently implement the latest hardware; they are no longer at the mercy of legacy vendors who go through a lengthy process of embedding and testing their software on each hardware release.

White box switches are based on commodity hardware from well-established vendors such as Accton, Delta Networks, Foxconn and Quanta Cloud Technology – the same companies that sell to the likes of Cisco and Juniper. Their switches are based on a choice of ASICS from vendors such as Broadcom, Cavium, Intel, Marvell and NVIDIA (which acquired Mellanox), all companies with long histories in producing network chipsets.

Brite box switches are based on similar hardware but carry a brand name, such as Dell Technologies or Edgecore Networks. But customers are free to run whatever network operating system they like on top.

In addition to choice and generally higher performance, the white/brite box approach offers significant capital cost savings vs. the premium prices that legacy vendors command.


The open approach also enables customers to run their choice of software, in terms of the network operating system running on top of their white/brite box switches and in the automation framework that drives the open IBN system.

Here again, that’s a significant difference from legacy vendors, which typically require you to be all-in with their hardware and software. An open approach doesn’t mean you have to toss all that legacy infrastructure, however – so long as your chosen software is compatible with that infrastructure.


In choosing an open IBN approach, you will likely find many of the tools employed are already in use in your organization. Systems management and DevOps teams, for example, may well be using the open source Ansible automation platform, the same one that drives many automation features in an open IBN implementation. These tools are proven, reliable components of leading edge IT projects and are well-positioned to change the way you approach enterprise networking.

The Pica8 Approach to Open IBN

Pica8’s approach to open IBN centers around the company’s AmpCon automation framework. It is the centralized Linux-based user interface where network policies are set and enforced, effectively making it a management platform for the enterprise network. It can be run from any point in the network and does not require any sort of dedicated server, as many legacy-vendor solutions do. And, again, in can run in concert with any number of other tools and management solutions as it does not need to grab control of a switch to function – unlike many of the legacy-vendor IBN offerings.

With AmpCon, companies can now extend open IBN throughout the network, from the data center (including private clouds) to the campus and the access edge. PICOS runs on an unmodified Debian Linux kernel, so it also supports numerous Linux tools and Ansible, enabling you to take advantage of its extensive library of automation routines as well as easily develop custom automations. (Pica8 provides a number of these Ansible “playbooks” as part of its AmpCon offering and customers are free to create their own as they see fit.)

PICOS likewise plays a key role. It uses the market-proven Free Range Routing (FFR) protocol stack and supports full Layer 2/Layer 3 network protocols, such as Open Shortest Path First (OSPF), Border Gateway Protocol (BGP), and multi-switch Link Aggregation Group (mLAG). PICOS also supports extensive software-defined network (SDN) protocols, including OpenFlow. In fact, Pica8 is the only networking vendor that can support L2/L3 and SDN running concurrently on the same switch port, making possible new levels of control and security capabilities.

PICOS supports extensive network virtualization technologies, such as Ethernet Virtual Private Network (EVPN) and Virtual Extensible LANs (VXLANs). EVPN is standards-based technology for providing bridged Layer 2 connectivity between sites or domains over an IP backbone. VXLANs help address scalability issues associated with cloud computing environments by encapsulating Layer 2 traffic for transport over a Layer 3 network. PICOS can control up to 2,000 VLANs or VXLANs in single network fabric, roughly twice as many as competing vendors, including Cisco. PICOS is also fully backward-compatible with all existing enterprise infrastructure, not just in the data center. As an enterprise-wide solution, most critically PICOS is interoperable with campus- and access-network network access control (NAC) and network address translation (NAT) software from Cisco and other legacy vendors.

Taken together, all these elements make it clear: Pica8 has the only viable open approach to implementing IBN throughout the enterprise, from the data center all the way to the access edge.

Open IBN is the Future

As networks continue to grow in size and complexity, a new approach to managing them is warranted. Pica8 PICOS and AmpCon provide just that with an open IBN implementation that represents the future of enterprise networking.

With Pica8’s open IBN architecture, you can reduce operational costs by automating day-to-day tasks, freeing up network staff for more strategic endeavors – and/or avoid hiring additional staff. At the same time, you’ll find IBN helps improve performance and uptime.

Pica8 helps you reduce capital costs by giving you access to lower-cost but powerful white/brite box switches and open source software. It all works with the legacy infrastructure you have in place, so you can take a gradual approach to implementing IBN.

Click here to learn more about how to realize your IBN future with Pica8’s open automation architecture.