Dynamic Service Configuration and Automated Network Configuration with NETCONF and YANG

Carl Moberg

VP of Engineering, Tail-f Systems

<calle@tail-f.com>

@cmoberg on twitter

2

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.

3

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

4

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)

5

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

6

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

7

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

8

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

9

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

10

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?

11

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

12

Thank Youwww.tail-f.cominfo@tail-f.com