<p align="center"> <img src="imgs/0frontpage.jpg"> </p>

• Network Programmability
  • The challenge of Dynamic applications vs Static network
  • What is Programmability
  • Why Coding
  • What has changed?
    • Modern Programming Languages & Tools
    • Online Communities
    • API Maturity
  • Coding essentials
    • YANG data models
    • JSON and XML
      • JSON
      • XML
    • NETCONF and RESTCONF
      • NETCONF
      • RESTCONF
    • REST APIs
    • API Documentation
    • Python
  • Summary
• NetDevOps
  • The challenge of network configuration today
  • Network configuration as code
• Demonstrations
  • Demo 1 - Automating network configuration from testing to production
    • GitLab setup
    • CICD setup
    • VIRL verifications
    • Local environment setup optional
    • Demo overview
    • Summary
  • Demo 2 - VPN Head End Management Platform HEMP
    • Topology
    • Building blocks
    • Environment setup
    • Demo overview
    • Summary
  • Demo 3 - Working with pyATS and Genie
    • Test a - Execute a command on a network device
    • Test b - Consolidate info from devices with different CLI
    • Test c - Develop your own tests with an interactive shell
    • Test d - Profiling your network for troubleshooting
    • Test e - Working with Test Cases
    • Test f - Check all BGP neighbors are established
  • Demo 4 - ChatOps is the way
    • Getting started with ChatOps
    • Webex basics
    • Bot logic
    • Connectivity and webhooks
    • Please call for details
    • Why don't you answer my messages?
    • Chuck Norris jokes and other useful APIs
    • Integration with Meraki API
  • Demo 5 - Network Services Orchestrator (NSO)
    • Compile MAC addresses
    • Network configuration compliance
    • Update SNMP community strings
  • Demo 6 - Model driven programmability for network services

Network Programmability

Do you often ask yourself why we keep configuring our network devices in the same way we have been doing it for the last 30 years? Isn't it strange that we still have to log into each individual box and use command-line instructions to perform any changes? Do you wonder if there might be a more optimal way of configuring your infrastructure, instead of CLI? Does this way of working make you feel like any simple change in your network is complex to implement?

You are not alone.

<p align="center"> <img src="https://media.giphy.com/media/paN2mV7vuCXx6/giphy.gif"> </p>

There are definitely alternative and innovative ways of programming your network infrastructure. Yes, when you configure your network devices to adopt a certain behaviour, or implement a new available feature, you are programming them. So one of the first things we should be looking for is more optimal ways of programming our infrastructure.

The challenge of Dynamic applications vs Static network

Furthermore, as the network exists to provide connectivity for applications, we should take a look at how these are evolving. Agile microservices-based cloud-native development, DevOps automation with CICD pipelines, and automated unit testing, enable really dynamic application development for quick time-to-market requirements. Let's not forget that software is one of the most important assets to differentiate modern enterprises from their competition. Being able to quickly implement new features, deploy new locations, or fix issues, is absolutely key to their success.

<p align="center"> <img src="imgs/1staticnw.jpg"> </p>

For the last years, servers have been virtualized with Virtual Machines that can be automatically deployed in minutes. These days the trend is going to container-based microservices, that are deployed insanely fast. These are short-lived entities that may be deployed dynamically across hybrid cloud environments, interacting among them to provide the desired service with virtually unlimited scalability, and adapting to any possible issues in the underlying infrastructure via declarative statements.

In comparison, network infrastructure is much more static. In order to accommodate requirements from application developers it needs to be faster, more flexible and cost-optimized. Today network configuration is often a completely manual process that makes any desired change across the network complex and slow. The more elements these changes include (eg. firewalls, load-balancers...) the more difficult it gets to make them quick, reliable and adaptable. This situation often leads to bare minimum configurations in the network, that allows for a faster deployment (eg. no security ACLs, no QoS config, or trunking every VLAN in an interface) but usually leading to much bigger concerns.

<p align="center"> <img src="imgs/2skeleton.jpg"> </p>

Infrastructure is full of products designed to be used by... humans. It may not always seem that way, but human operators are the target users for CLI and web interfaces. This means that when you need to get something done via these interfaces, you (or some other human) has to do the work.

You won't have to think back too far to remember the last time you needed to complete some bulk-task on a computer. The task probably involved a lot of clicking, typing, copying-and-pasting, or other mind-numbing repetitions. These human interfaces (and the paradigm of having humans do the work) are to blame for the bulk-work that we sometimes have to do to complete a task.

Our brain has a great capacity, but clearly human input/output interfaces with a computer (typing and reading) are not very fast. Our thoughts neck down to this tiny straw, which output-wise is like poking things with your meat sticks, or using words (speaking or tapping things with fingers). For example, machine typing usually happens at a 20th of the speed you are thinking. And I am talking ten-finger typing, let's not even go into two-thumb typing... So while Elon Musk finishes his BMI (Brain Machine Interface), aka Wizard Hat, we will have to explore alternative options that optimize how we configure our networks.

<p align="center"> <img src="imgs/2elon.png"> </p>

What is Programmability

Computers are great at bulk-work, but if you want your computer to talk to your infrastructure and do something, you will need a machine-to-machine interface or API (Application Programming Interface): an interface designed for software pieces to interact with each other.

By 2020, only 40% of network operations teams will use the command line interface (CLI) as their primary interface, which is a decrease from 75% in 2Q18. (Gartner, 2018 Strategic Roadmap for Networking)

Network Programmability uses a set of software tools to deploy, manage and troubleshoot network devices and controllers via APIs, gathering data and driving configurations to enhance and secure application delivery. This software can on-box or off-box, and work on-demand or event-driven.

We can ask an API to:

• Take some action
• Provide us with some piece of information
• Store some piece of information

We use these machine-to-machine APIs to make simple requests to our infrastructure, which in aggregate, enable us to complete powerful tasks.

For example, you might use APIs to make simple requests like...

• Get the status for interface X
• Get the last-change time for interface X
• Shutdown interface X
• Set the description of interface X to "Interface disabled per Policy"

... and that way complete a powerful task like: "Disable all ports that have been inactive for 30 days."

Sure, you could do this manually, but wouldn't it be better to codify the process (write it once) and then let your computer run this task whenever you need it done?

Besides this, information included in API responses should be formed by data structures