SHARE



ABOUT THE AUTHOR


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 >>
SHARE



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.





COMMENTS



Enterprise Connect Orlando 2017
March 27-30 | Orlando, FL
Connect with the Entire Enterprise Communications & Collaboration Ecosystem


Stay Up-to-Date: Hear industry visionaries in Keynotes and General Sessions delivering the latest insight on UC, mobility, collaboration and cloud

Grow Your Network: Connect with the largest gathering of enterprise IT and business leaders and influencers

Learn From Industry Leaders: Attend a full range of Conference Sessions, Free Programs and Special Events

Evaluate All Your Options: Engage with 190+ of the leading equipment, software and service providers

Have Fun! Mingle with sponsors, exhibitors, attendees, guest speakers and industry players during evening receptions

Special Offer - Save $200 Off Advance Rates

Register now with code NOJITTEREB to save $200 Off Advance Rates or get a FREE Expo Pass!

March 8, 2017

Enterprise IT's ability to innovate is critical to the success of the business -- 80% of CIOs agree. But the CIO role has never been more challenging than it is today, with rising operational respo

February 22, 2017

Sick of video call technology that make participants look like they're in the witness protection program? Turns out youre not alone. Poor-quality video solutions can give users an unprofessional ap

February 7, 2017

Securing voice communications used to be very simple since it was generally a closed system. However, with unified communications (UC) you no longer have the walled protection offered by a dedicate

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.