A 30-minute Introduction to NETCONF and YANG

Carl Moberg <calle@tail-f.com>

twitter: @cmoberg

Last updated 2011-11-18

2

Document Introduction

• This is a live documentation that I use to present the state of NETCONF and YANG in various contexts

• I use it to inform and get conversation going, not to provide complete and final documentation of NETCONF and YANG

• I update this document roughly quarterly, mostly with regards to industry support and working group timelines, check back or get in touch!

3

Some Background

• NETCONF is an IETF configuration management protocol and YANG is its data modeling language

• In response to SNMP/SMI shortcomings for managing configuration e.g.:– Lack of support for simple things like backup-and-restore of element

configuration– No concept of transactions (single- or multibox)– Many inherent limitations in SMI (e.g. label length)

• Lots of background text in RFC 3535 Overview of the 2002 IAB Network Management Workshop

4

NETCONF and YANG Brief Timeline

NETCONF• 2001

IETF Meeting with poll of SNMP SET usage

• June 2002IAB Network Mgmt Workshop

• May 2003NETCONF WG established

• Dec 2006NETCONF core RFCs published

YANG

• 2007YANG design team proposal

• Apr 2008NETMOD WG established

• Oct 2010YANG RFC 6020 published

5

So What is NETCONF?

• NETCONF is an IETF network management protocol designed to support management of configuration, including:– Distinction between configuration and state data – Multiple configuration data stores (candidate, running, startup)– Configuration change validations– Configuration change transactions – Selective data retrieval with filtering– Streaming and playback of event notifications– Extensible remote procedure call mechanism

6

Ok, So What is YANG

• YANG is a data modeling language designed to write data models for the NETCONF protocol. It provides the following features:– Human readable, and easy to learn representation – Hierarchical configuration data models– Reusable types and groupings (structured types)– Extensibility through augmentation mechanisms– Supports definition of operations (RPCs)– Formal constraints for configuration validation– Data modularity through modules and sub-modules– Well defined versioning rules

7

NETCONF Layering Model

Content

Operations

RPC

TransportProtocol

Configuration Data

<get> <get-config>

<rpc><rpc-reply>

SSH, SSL, BEEP, etc

Layer NETCONF

<notification>

8

Basic NETCONF Operations

• Get configuration <get-config>– Retrieve all or part of a specified configuration from a named data store

• Get all information <get>– Retrieve running configuration and device state information

• Edit configuration <edit-config>– Loads all or part of a specified configuration to the specified target configuration

• Copy configuration <copy-config>– Create or replace an entire configuration datastore with the contents of another

complete configuration datastore.

• Delete configuration <delete-config>– Delete a configuration datastore (not applicable to running)

• Lock and unlock <lock>, <unlock>– Short-lived lock and unlock of the configuration system of a device

• Close and kill session <close-session>, <kill-session>– Graceful (close) or forced (kill) termination of a NETCONF session

9

YANG Feature Highlights

• YANG definitions directly map to NETCONF (XML) content• YANG uses a compact C and Java-like syntax with

readability is highest priority• Data type system leverages work done for next-generation

SNMP type system accommodating XML and XSD requirements

• YANG can be formally translated to DSDL (RelaxNG, Schematron and DSRL) as described in RFC 6110

• There is also an informal translation to W3C XML Schema in the pyang tool

10

YANG Feature Highlights (cont’d)

• Organization– Leaf, leaf-list, container, lists, grouping, choice

• Data model structure– Module, submodule, augment, if-feature, when

• Constraints– Must, unique, min-elements, max-elements, mandatory

• Data types– Many built-in types, sub-typing, restrictions

• Reusable groupings– Grouping, uses

11

YANG Example

module acme-system { namespace "http://acme.example.com/system"; prefix "acme”;

organization "ACME Inc.”; contact "joe@acme.example.com";

description "The module for entities implementing the ACME system.”; revision 2007-11-05 { description "Initial revision.”; }

container system { leaf host-name { type string; description "Hostname for this system”; }

12

YANG Example (cont’d)

list interface { key "name"; description "List of interfaces in the system”; leaf name { type string; } leaf type { type string; } leaf mtu { type int32; } } }}

13

Known NETCONF Vendor Implementations

– Alaxala• Ethernet switches

– BATM/Telco Systems• T-Metro 7224

– BigBand• MSP2800

– Brocade• NetIron XMR, CES, and CER• MLX Series• VDX (Announced, not released)

– Cisco• IOS 12.4(9)T and later• IOS XE 2.1 and later

– Edgeware• WTV-2X

– Ericsson• SEA 20

– H3C• S9500E Series Routing Switches

– Huawei• AR3200/2200 Enterprise Routers

– Juniper Networks• JUNOS 7.5 and later

– Nexor• Messaging Gateways

– RuggedCom• RX5000 and MX5000

– Sonus• NBS5200 Session Border Controller

– Taseon• TN 320

– Verivue• MDX 9020

Please Note that this list is work in progress and feedback on accuracy and completeness is strongly encouraged

Entries in italics is new in this version of the presentation

14

Available NETCONF Implementations

Commercial Products– Applied Informatics

• POCO NETCONF (server)

– Centered Logic• NetconfX (client)

– Oracle/GoAhead• NETCONF MindAgent (server)

– SNMP Research• EPIC NETCONF (server)

– Tail-f Systems• ConfD (server)• NCS (client)

– Velankani• NOCVue ConfigMan

– WebNMS• WebNMS Framework (client)

Open Source Projects– Ncclient (client)– NetconfX (client)– Netconf4Android

(client)– netconf4j (client)– netopeer (client/server)– YencaP (client/server)– Yuma (client/server)

Please Note that this list is work in progress and feedback on accuracy and completeness is strongly encouraged

15

Available YANG Implementations

• Commercial Products– MG Soft Corporation– Oracle/GoAhead– SNMP Research– Tail-f Systems

• Open Source Projects– jYang– libsmi– Pyang– yang-mode for Emacs– Yuma

Please Note that this list is work in progress and feedback on accuracy and completeness is strongly encouraged

16

Standards Organizations Activities

• IETF

– NETCONF working group focusing on:

• Access Control• System Notifications

– NETMOD (YANG) working group currently focusing on:

• Interfaces, routing and system data modules

• SMIv2-to-YANG translation

– Always updated:• http://tools.ietf.org/wg/netconf/• http://tools.ietf.org/wg/netconf/

– YANG models for Service OAM PM and FM

– To be published

– YANG module for CCAP: next generation cable head-end systems

– Part of the Converged Cable Access Platform Support System Interface Specification

Please Note that this list is work in progress and feedback on accuracy and completeness is strongly encouraged

17

Further Reading

• IETF NETMOD and NETCONF WG pages:– http://trac.tools.ietf.org/wg/netconf/trac/wiki– http://trac.tools.ietf.org/wg/netmod/trac/wiki

• NETCONF Central– http://www.netconfcentral.org/

• YANG Central– http://www.yang-central.org/twiki/bin/view/Main/WebHome

• Instant YANG – an Introduction– http://www.tail-f.com/instant-yang-primer

• The NETCONF and YANG Users LinkedIn Group– http://www.linkedin.com/groups/NETCONF-YANG-Users-3301774

18

19

Backup Slides

20

Why not use XSD?

• XSD defines the syntax of XML instance documents, • YANG defines the semantics of a configuration data model

and the syntax of XML

• For more in-depth reading:– Why we need a NETCONF-Specific Modeling Language (draft-

lengyel-why-yang-00.txt)– Comparing Approaches to NETCONF Modeling (CANMOD) BOF

(http://tools.ietf.org/agenda/71/canmod.html)

21

A Layered Comparison

SNMP NETCONF SOAP

Data models MIBs Modules

Data Modeling Language

SMI YANG

Management Operations

SNMP NETCONF

RPC Protocol BER XML XML

Transport Stack UDP SSHBEEPSOAPTLS

SSLHTTPTCP