This document discusses dynamic service configuration and automated network configuration using NETCONF and YANG. It summarizes the problem with a lack of standardization in network device configuration historically. NETCONF and YANG are introduced as a solution, with NETCONF providing a protocol for managing network devices and YANG providing a data modeling language. The document argues this approach will improve service quality, reduce costs for provisioning software and operational staff compared to the current proprietary and manual approaches.

1. Dynamic Service Configuration and
Automated Network Configuration
with NETCONF and YANG
Carl Moberg<calle@tail-f.com>
@cmoberg on twitter
Version 2010-09-20

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  The YANG Language:
Protocol: • Human readable
• Distinctionbetweencon • Formal constraints
figurationandstatedata • Hierarchical
• Change validations • Extensibilitythrough
• Multi-box Transactions augmentation
• Selectivedata retrieval
• ExtensibleRPCs

9. Impact on Service Automation
Before After
 Service Quality  Service Quality
• High failure rates • Validated changes
• Network inconsistencies • Transactions
 Provisioning Software  Provisioning Software
• Heavy, expensive device • Device abstractions is
abstractions inherent to protocol
• Least common • Focus on value-added
denominator features features
 Operational Staff  Operational Staff
• Commonly part of the • Tasks that can be, will be,
automation loop automated
• Vendor-specific expertise • Vendor-specific expertise
for common tasks 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 notgood 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 You!