Version 2023-04-13

Dynamic Service Configuration and Automated Network Configuration

with NETCONF and YANG

Carl Moberg <calle@tail-f.com>

@cmoberg on twitter

Introducing Myself

VP Engineering at Tail-f Systems with background in Network Operations (AS1299 and AS3301)

Have had head under the hood of many network products with recurring nightmares from what I’ve seen:• “We didn’t really think about a ‘show config’ command”• “So what you’re saying is that operators normally expects a CLI

on the box?”

On-device OAM is more often than not an afterthought in terms of resources and timing…

…which is the main contribution to our current situation.

The Problem

The problem is: historically no standard (formal or informal) for configuration management

It is a problem because: impedance between service and infrastructure domains can only be solved by large amounts of manual labor, code and risk

How bad is it?

Things that one would expect be possible:• “I’d like to apply this change across two or more boxes and

automatically roll both back if one fails”• “I’d like to back up configuration from one box and store it for

later rollback”

Ways to address this:• Make changes manually using expert resources (opex)• Develop and maintain abstraction in house (direct capex)• Third party to develop and maintain abstraction (indirect capex)

Current Service Automation

Network-oriented services are increasingly:• Complex• High frequency• Costly to fail• Scaling up

Examples network-oriented services:• Enterprise VPNs - network order failures delay customer access• Mobile Backhaul - delay in provisioning impacts cell opex• VLAN provisioning for virtualized workloads - just won’t work

Impact on Service Automation

Service Quality• High failure rates• Network inconsistencies

Provisioning Software• Heavy, expensive device abstractions• Least common denominator-features

Operational Staff• Commonly part of the automation loop• Vendor-specific expertise for common tasks

Introducing a Solution

Operators told the IETF in 2001 that they saw no developments addressing their configuration management protocols

This is documented in RFC 3535 Document work timeline:

• 2002 – Network Management Workshops• 2006 – NETCONF base RFC published• Now – YANG standard document in final phase

NETCONF and YANG Highlights

The NETCONF Protocol:• Distinction between

configuration and state data

• Change validations• Multi-box Transactions• Selective data retrieval• Extensible RPCs

The YANG Language:• Human readable• Formal constraints• Hierarchical• Extensibility through

augmentation

Impact on Service Automation

Before

Service Quality• High failure rates• Network inconsistencies

Provisioning Software• Heavy, expensive device

abstractions• Least common

denominator features

Operational Staff• Commonly part of the

automation loop• Vendor-specific expertise

for common tasks

After

Service Quality• Validated changes• Transactions

Provisioning Software• Device abstractions is

inherent to protocol• Focus on value-added

features

Operational Staff• Tasks that can be, will be,

automated• Vendor-specific expertise

for vendor specific features

Looking Ahead

We are climbing a giant, heading for shoulders:• The network as a schema-driven database?• How dynamic do we want the network to be?• Next useful layer of abstraction?

Thoughts on industry impact:• How open will vendors want to be? Can they?• New breed of third party automation vendors?• Impact on standards?

Conclusions

Current state of industry is legacy, proprietary (or both) and not good enough

Everything possible with programming but cost and risk remains

NETCONF and YANG is a solution with focus on the core of the problem

Interesting times ahead

Thank You!