Terry Slattery
Terry Slattery, is a senior network engineer with decades of experience in the internetworking industry. Prior to joining Chesapeake NetCraftsmen as...
Read Full Bio >>

Terry Slattery | April 01, 2015 |


Why You Need to Know About Promise Theory

Why You Need to Know About Promise Theory Promise theory enables scalable and simpler network configuration control

Promise theory enables scalable and simpler network configuration control

I encountered the term "promise theory" while learning about Cisco's Application Centric Infrastructure (ACI) and the associated Application Policy Infrastructure Controller (APIC). OK, time out! What is promise theory? I needed to do some research on this concept.

I quickly found a Wikipedia explanation, which led me to the information on Mark Burgess, a computer scientist who seems to be the author of the concept. Still, these pages didn't do much for educating me on the subject so I then watched Mark's promise theory Google TechTalk and read his blog.

Still feeling a little bit in the dark, I resumed researching Cisco's ACI while I let the new knowledge percolate in my brain. It finally started to make sense, probably due to some other things I read about ACI and APIC and the use of promise theory in their operations. A fundamental concept of promise theory is that it uses declarative control instead of imperative control.

Imperative Control
An imperative control system describes and executes each step of a process to achieve a desired result. For example, to apply quality-of-service (QoS) queuing definition to the core of a network, we would implement the following steps:

  1. Define QoS queues and traffic rate limits.
  2. Determine the set of non-edge switches and routers.
  3. For each type of router or switch, determine the specific commands to implement the desired queuing with rate limits and add those commands to the device configuration. These configurations are very detailed descriptions of what the devices should do.
  4. Optionally create a policy to verify that the desired QoS configuration remains unchanged so that we can find future exceptions to the desired configuration.

The important point of imperative control is that the system being controlled contains no intelligence. All the intelligence is in the control system. It is a centralized model, even when the individual devices being controlled are distributed.

Another interesting point is that if the commands are executed more than once by an imperative control system, a different final state may be created. For example, if control statements add configuration commands to an existing configuration, performing the same commands again may result in two copies of the commands in the configuration. Only through careful selection of the control statements can those control statements be executed more than once, with the end result being the same. In other words, the execution of the control statements may not be an idempotent operation, which is a repeatable operation well-known in the programming world. (Note: Network engineers will need to understand terms like "idempotent" to communicate with software-defined networking software developers.)

Declarative Control
A declarative control system communicates what should happen, not how it should be done. It is up to the endpoints to implement what the control system communicates. Following our QoS example, we have a very different control system.

  1. Determine the QoS queues and rate limits. This is the same as what we saw with the imperative control system.
  2. Communicate the queue structure and threshold limits to the devices that incorporate the QoS promises.
  3. Each device changes its configuration to match the desired state.

The control system doesn't know what steps each device takes to achieve the desired configuration state. The devices simply implement the promises required to achieve the desired state. This control system is idempotent. It allows the control system to repeat the instructions more than once with the confidence that the final state will be the same. In the QoS example, a router or switch would promise to forward all traffic marked EF (Express Forwarding, DSCP 46) in the high-priority queue, up to the specified rate limits. The specific configuration commands needed to implement this configuration within the device are not known to the central control system.

How Does This Relate to Promise Theory?
Promise theory states that the devices promise to implement a desired state requested by the control system. So in the QoS example above, the devices in the declarative control system promise to implement the desired QoS queues and rate limits. The promises can be implemented either within the devices or within an interface layer that communicates with the device.

Another advantage of promise theory is that the configuration control is distributed. The implementations of the promises that a device can make are specific to that device. The central control system no longer has to be capable of configuring every different device. It simply issues the declarative commands and it is up to each device that supports the desired promises to implement them. If a device can't deliver on the promise, perhaps because limited internal resources are fully committed, then it would return an error to the controller.

The distributed nature of the promise theory implementation on each device is a significant advantage. It means that the configuration control system doesn't have to include the detailed configuration control elements for each device it may need to control. Instead, devices are distributed with the promise theory control function, either internally or as a small library added as an interface module in the control system.

Historically, we've had network management systems (NMS) shipped many months after vendors release devices. This is because the NMS vendor needed to add the imperative control system components for the new devices. But with promise theory, the device vendor can ship the promise theory control module with the device, implementing a known set of promises. This decouples device releases from NMS releases. What a splendid idea. Promises seem to be a good abstraction upon which to build.

Vendors are building real systems around promise theory. One of the first is CFEngine, which Mark created to manage configurations of Linux systems. It is exciting to see promise theory also being incorporated into networking systems such as Cisco's ACI and APIC.


April 19, 2017

Now more than ever, enterprise contact centers have a unique opportunity to lead the way towards complete, digital transformation. Moving your contact center to the cloud is a starting point, quick

April 5, 2017

Its no secret that the cloud offers significant benefits to enterprises - including cost reduction, scalability, higher efficiency, and more flexibility. If your phone system and contact center are

March 22, 2017

As today's competitive business environments push workforces into overdrive, many enterprises are seeking ways of streamlining workflows while optimizing productivity, business agility, and speed.

April 20, 2017
Robin Gareiss, president of Nemertes Research, shares insight gleaned from the firm's 12th annual UCC Total Cost of Operations study.
March 23, 2017
Tim Banting, of Current Analysis, gives us a peek into what the next three years will bring in advance of his Enterprise Connect session exploring the question: Will there be a new model for enterpris....
March 15, 2017
Andrew Prokop, communications evangelist with Arrow Systems Integration, discusses the evolving role of the all-important session border controller.
March 9, 2017
Organizer Alan Quayle gives us the lowdown on programmable communications and all you need to know about participating in this pre-Enterprise Connect hackathon.
March 3, 2017
From protecting against new vulnerabilities to keeping security assessments up to date, security consultant Mark Collier shares tips on how best to protect your UC systems.
February 24, 2017
UC analyst Blair Pleasant sorts through the myriad cloud architectural models underlying UCaaS and CCaaS offerings, and explains why knowing the differences matter.
February 17, 2017
From the most basics of basics to the hidden gotchas, UC consultant Melissa Swartz helps demystify the complex world of SIP trunking.
February 7, 2017
UC&C consultant Kevin Kieller, a partner at enableUC, shares pointers for making the right architectural choices for your Skype for Business deployment.
February 1, 2017
Elka Popova, a Frost & Sullivan program director, shares a status report on the UCaaS market today and offers her perspective on what large enterprises need before committing to UC in the cloud.
January 26, 2017
Andrew Davis, co-founder of Wainhouse Research and chair of the Video track at Enterprise Connect 2017, sorts through the myriad cloud video service options and shares how to tell if your choice is en....
January 23, 2017
Sheila McGee-Smith, Contact Center/Customer Experience track chair for Enterprise Connect 2017, tells us what we need to know about the role cloud software is playing in contact centers today.