Originally written by Derick Winkworth at the Plexxi blog.

In networking, workflows are awfully complicated.  There are many workflows, and the exact nature of each depends on a number of variables.  What task comes next is often dependent on the outcome of the previous task, and there is a large amount of data to navigate sometimes to complete a workflow.  Nevertheless, there plenty of opportunity to identify and automate common tasks and segments of workflows.  Once we’ve identified these, we need to ask ourselves, how exactly should we automate them?

Encapsulation

“Encapsulation” means a vendor (possibly a third party vendor) has written software that accomplishes the same thing the workflow does, but usually not the in the same linear way a customer would do it.  Sub-components within an encapsulation have well-designed interfaces for the purpose of accomplishing the goal.  The encapsulation would likely be written in Java or C.  In networking, encapsulated workflows are usually specific to a vendor’s product and often lack flexibility and features.  Encapsulated workflows will manifest as products or product features.

Consider the following workflow:

Figure 1 shows a simplified packet walk-through for a device.  Here, in the course of evaluating what is happening to a packet passing through this device, we have discovered a filter policy applied to the ingress interface.  This policy has two terms, and each of these terms references an access-list.  A network engineer would need to evaluate this filter policy to determine if it is doing something to the packets of interest.  The thing is, policy languages have a great deal of expressiveness and grammar.  They are also proprietary.  After the filter policy is evaluated, this workflow follows the forwarding pipeline to the egress interface.  If you are an experienced network engineer, you will know that there are other elements in the pipeline that should be checked for any given network device.  However, there is enormous variation in the structure of the pipeline from one platform to the next.  Therefore, this is a great candidate for discrete encapsulation.* There are more effective ways of achieving the goal of a packet walk-through than the way a network engineer must do it now (particularly for SDN products), and vendors know their platforms and policy idioms best.

*Discrete means it’s a workflow with a beginning and an end.  It can be manually invoked by a user, and runs for a finite amount of time, reaching some conclusion.

Automation

A workflow automation, on the other hand, consists of sub-components that are “glued together.”  These components were not built especially for automation, and the interfaces between these components were not designed for any particular workflow.  Automations can be developed by the customer, and very frequently discrete automations are employed by network engineers.  A great example here would be a script to configure the login banner on some number of devices.  These automations are written in “softer” languages like Python or Perl.

There is a clear need for Continuous Automation in networking.  Plexxi’s own DSE, now an integral part of the OpenStack Congress project, attempts to address this need.  As the name implies, Continuous means it’s an on-going process.  In the case of the Congress, it is a modular, event/data driven system.  In an environment where there are a plethora of protocols and APIs, each with their own idiosyncrasies, this kind of automation makes sense.  Particularly in the context of an open-source community.

Hybrid

Curiously, some workflows may best be addressed by a combination of automation types.  For instance, if a customer wanted to know what was going on in the network relative to a particular application, that workflow automation could use the packet walk-through encapsulation of a vendor combined with an automation tool like the DSE to harvest network meta-data from external systems about application endpoints.  This could yield a network map of the application’s endpoints along with visual indicators of issues in the network that could be impacting to the application.  In this way, the network engineer could quickly and accurately gauge the health of the network in the context of an application versus engaging in a tedious and error-prone search “by hand.”

Conclusion

Customers, vendors, and open source communities should work together to make networking better.  Identifying common workflows and determining the best way to automate them is a good first step.  This will require vendors to think differently about how they develop their products, with their user’s needs in mind first.  Traditionally, just getting a network feature to work and inter-operate was the goal, but now we must consider how this feature fits into common workflows performed by network engineers.