Tutorial: NETCONF and YANG

Presented by Stefan Wallin, Tail-f

[email protected]
 Today’s Topic: #1 Market Leader in Configuration Management

©2013 TAIL-F all rights reserved 2

 Origins of NETCONF and YANG (the Beginning)

•  Several meetings at events in 2001 (NANOG-22, RIPE-40, LISA-XV,

IETF 52)
•  Operators expressing opinion that the developments in IETF do not really
address requirements configuration management.
•  June of 2002, the Internet Architecture Board (IAB) held invitational
workshop on Network Management [RFC3535] to
•  Identify a list of technologies relevant for network management with their
strengths and weaknesses
•  Identify the most important operator needs.

May 11, 2014 ©2013 TAIL F all rights reserved 3

 Best Practices Coming Together

CLI  Best  Prac5ces  

Operator  
SNMP  Experience   Requirements  

NETCONF  and  
YANG  

May 11, 2014 ©2013 TAIL F all rights reserved 4

 Agenda

• Quick Overview (RFC 6244, 2011)

• Background and Motivation (RFC 3535, 2003)
• NETCONF (RFC 6241, 2006, 2011)
• YANG (RFC 6020, 2010)
• Complete Example
• Demo

May 11, 2014 ©2013 TAIL F all rights reserved 5

TUTORIAL: NETCONF AND YANG

NETCONF and YANG

What is it?

©2013 TAIL-F all rights reserved MAY 27, 2013 6

TUTORIAL: NETCONF AND YANG

NETCONF and YANG in Context

Yang   YANG Modules

ManagementModels  
Applications
NETCONF
Manager

NETCONF

YANG Modules YANG Modules YANG Modules

©2013 TAIL-F all rights reserved MAY 27, 2013 7

TUTORIAL: NETCONF AND YANG

What is a Data-Model? What is a Network Management Protocol?

•  Data-Model
•  A data-model explicitly and precisely
determines the structure, syntax and
Protocol   semantics of the data…
•  …that is externally visible
•  Consistent and complete
•  Protocol
Data-Model •  Remote primitives to view and manipulate the
data
•  Encoding of the data as defined by the data-
model

©2013 TAIL-F all rights reserved MAY 27, 2013 8

TUTORIAL: NETCONF AND YANG

Confusion and Comparison

•  Data-Models and information Models

•  Information models are for humans
•  Not  everything  
Protocol   •  Not  always  detailed  and  precise  
The  SNMP  Protocol   •  Star5ng-­‐point  for  data-­‐model  
NETCONF   •  Protocol
•  Confusion between domain-specific network
management protocols and general RPC
mechanisms
Data-Model •  NETCONF  vs.  SOAP,  REST,  …  
 MIB  Modules  
 YANG  Modules  

©2013 TAIL-F all rights reserved MAY 27, 2013 9

TUTORIAL: NETCONF AND YANG

NETCONF – A Protocol to Manipulate Configuration

•  IETF network management protocol

•  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

Why you should care:

NETCONF provides the fundamental
programming features for comfortable and
robust automation of network services

©2013 TAIL-F all rights reserved MAY 27, 2013 10

TUTORIAL: NETCONF AND YANG

YANG – A Data Modeling Language for Networking

•  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
Why you should care:
YANG is a full, formal contract language with
rich syntax and semantics to build
applications on

©2013 TAIL-F all rights reserved MAY 27, 2013 11

TUTORIAL: NETCONF AND YANG

Who ?

NETCONF YANG
•  Phil Shafer, Rob Enns •  Phil Shafer
•  Juniper
•  Juniper, XML
•  Jürgen Schönwälder
•  Jacobs University •  Jürgen Schönwälder
•  Martin Björklund •  Jacobs University, SNMP SMIng
•  Tail-f

•  Andy Bierman
•  Martin Björklund
•  Yumaworks •  Tail-f
Ken Crozier Eliot Lear
• 
•  David Partain
•  Cisco Systems
•  Ericsson, made it happen
•  Ted Goddard
•  IceSoft

•  Steve Waldbusser
•  Margaret Wasserman
•  Painless Security, LLC

©2013 TAIL-F all rights reserved MAY 27, 2013 12

TUTORIAL: NETCONF AND YANG

Language Bindings

©2013 TAIL-F all rights reserved MAY 27, 2013 13

TUTORIAL: NETCONF AND YANG

Momentum

©2013 TAIL-F all rights reserved MAY 27, 2013 14

Standards background, motivation and history
RFC 3535: Operators’ problems and requirements on network
management
TUTORIAL: NETCONF AND YANG

Informational RFC 3535

Abstract •  SNMP had failed

This document provides an overview of a •  For configuration, that is
workshop held by the Internet Architecture •  Extensive use in fault handling
Board (IAB) on Network Management. The and monitoring
workshop was hosted by CNRI in Reston,
•  CLI scripting
VA, USA on June 4 thru June 6, 2002. The
goal of the workshop was to continue the •  “Market share” 70%+
important dialog started between
network operators and protocol
developers, and to guide the IETFs focus
on future work regarding network
management.

configuration  

©2013 TAIL-F all rights reserved MAY 27, 2013 16

TUTORIAL: NETCONF AND YANG

Operator Requirement #1/14

1. Ease of use is a key requirement for Maybe  not  assume  integrators  and  
any network management technology soLware  developers  for  any  addi5on  
from the operators point of view. or  change  

Manage  

©2013 TAIL-F all rights reserved MAY 27, 2013 17

TUTORIAL: NETCONF AND YANG

Operator Requirement #2-3/14

2. It is necessary to make a clear •  Clearly separating configuration

distinction between configuration •  Ability to compare across devices
data, data that describes operational
state and statistics.
3. It is required to be able to fetch
separately configuration data,
operational state data, and statistics from
devices, and to be able to compare these
between devices.
$show running-config

©2013 TAIL-F all rights reserved MAY 27, 2013 18

TUTORIAL: NETCONF AND YANG

Operator Requirement #4-5/14

4. It is necessary to enable operators to •  Service and Network management, not

concentrate on the configuration of the only device management
network as a whole rather than •  Network wide transactions
individual devices.
5. Support for configuration
transactions across a number of devices
would significantly simplify network
configuration management.

VPN  Configura5on  

All  or  nothing  

©2013 TAIL-F all rights reserved MAY 27, 2013 19

TUTORIAL: NETCONF AND YANG

Operator Requirement #6-7/14

6. Given configuration A and configuration •  Devices figure out ordering

B, it should be possible to generate the •  No unnecessary changes
operations necessary to get from A to B
with minimal state changes and effects on •  Finally: backup/restore of
network and systems. It is important to configuration
minimize the impact caused by
configuration changes.
The  litmus-­‐test  of  a  management  interface  
7. A mechanism to dump and restore
configurations is a primitive operation
needed by operators. Standards for pulling
and pushing configurations from/to
devices are desirable.

configura5on  

©2013 TAIL-F all rights reserved MAY 27, 2013 20

TUTORIAL: NETCONF AND YANG

Operator Requirement #8, 10/14

8. It must be easy to do consistency •  Validation of configuration

checks of configurations over time and •  Validation at network level
between the ends of a link in order to
determine the changes between two •  Text based configuration
configurations and whether those
configurations are consistent.
10. It is highly desirable that text
processing tools such as diff, and version
management tools such as RCS or CVS,
can be used to process configurations, Text  
which implies that devices should not
arbitrarily reorder data such as
access control lists. VPN  Configura5on  
Valid?  

©2013 TAIL-F all rights reserved MAY 27, 2013 21

TUTORIAL: NETCONF AND YANG

Operator Requirement #9/14

9. Network wide configurations are •  Standardized data models

typically stored in central master
databases and transformed into formats
that can be pushed to devices, either by
generating sequences of CLI commands
or complete configuration files that are Interfaces  Data-­‐Model  
pushed to devices. There is no common
database schema …, although the
models used by various operators are
probably very similar.
It is desirable to extract, document, and
standardize the common parts of these
network wide configuration
database schemas.

©2013 TAIL-F all rights reserved MAY 27, 2013 22

TUTORIAL: NETCONF AND YANG

Operator Requirement #13/14

13. It is important to distinguish between •  Support for multiple configuration sets

the distribution of configurations and •  Delayed, orchestrated activation
the activation of a certain configuration.
Devices should be able to hold multiple
configurations.

Config,  Config,  Commit  

©2013 TAIL-F all rights reserved MAY 27, 2013 23

TUTORIAL: NETCONF AND YANG

Operator Requirement #11,12,14/14

11. … Typical requirements are a role- •  Role-Based Access Control (RBAC)

based access control model and the •  Data oriented
principle of least privilege, where a user
•  Task oriented
can be given only the minimum access
necessary to perform a required task.
12. It must be possible to do consistency
checks of access control lists across
devices.
14. SNMP access control is data-oriented,
while CLI access control is usually
command (task) oriented. … As such, it is
a requirement to support both data-
oriented and task-oriented
access control

©2013 TAIL-F all rights reserved MAY 27, 2013 24

TUTORIAL: NETCONF AND YANG

Implications of RFC 3535, legacy situation

OSS
NMS
EMS
NETCONF
Manager

Cost  and  
complexity  
•  No well-defined protocols and
data-models
•  Lack of atomicity
•  Ordering problem

©2013 TAIL-F all rights reserved MAY 27, 2013 25

TUTORIAL: NETCONF AND YANG

Implications of RFC 3535, with transactions

OSS
NMS
EMS
NETCONF
Manager

Reduced  
Cost/  
Cost  and  
Value  
complexity  
Transac5ons  
Models  
Standardized  
Protocols  

©2013 TAIL-F all rights reserved MAY 27, 2013 26

TUTORIAL: NETCONF AND YANG

Introduction to NETCONF

©2013 TAIL-F all rights reserved MAY 27, 2013 27

TUTORIAL: NETCONF AND YANG

What makes NETCONF/YANG different?

SNMP NETCONF SOAP REST

Standard IETF IETF W3C -

Resources OIDs Paths URLs

Data models Defined in MIBs YANG Core

Models

“RESTConf”  
Data Modeling SMI YANG (WSDL, not data) Undefined, (WSDL),
Language WADL, text…

Management SNMP NETCONF In the XML HTTP operations

Operations Schema, not
standardized

Encoding BER XML XML XML, JSON,…

Transport Stack UDP SSH SSL SSL

TCP HTTP HTTP
TCP TCP
©2013 TAIL-F all rights reserved MAY 27, 2013 28
TUTORIAL: NETCONF AND YANG

NETCONF Features

•  API to configure network devices

Client  
•  XML RPC mechanism
Applica5on  
•  Connection-oriented (SSH)
•  Closely mirrors the device functionality
•  Capability Discovery
•  Separation of configuration and state data
•  Sub-tree filtering

Server  
Device  

©2013 TAIL-F all rights reserved MAY 27, 2013 29

TUTORIAL: NETCONF AND YANG

Layers

Config   No5fica5on  
Content  
Data   Data  

<EDIT-­‐CONFIG>  
Opera5ons  
<GET-­‐CONFIG>  

<RPC>  
Messages   <NOTIFICATION>  
<RPC-­‐REPLY>  

Secure  
SSH  
Transport  

©2013 TAIL-F all rights reserved MAY 27, 2013 30

TUTORIAL: NETCONF AND YANG

NETCONF Capabilities

•  A capability is a set of functionality •  Base NETCONF specification

that supplements base NETCONF provides very restricted set of
spec operations for lightweight server
implementations
•  Capabilities augment:
•  Additional operations
•  Content allowed inside these operations
•  Capabilities advertised by server
during session establishment

©2013 TAIL-F all rights reserved MAY 27, 2013 31

TUTORIAL: NETCONF AND YANG

NETCONF Configuration Data Stores

Copy   Copy  

Candidate   Running   Startup   Files…  /  URLs…  

Always!  
Commit   Only  one!  

•  Named configuration stores

•  Each data store may hold a full copy of the configuration
•  Running is mandatory, Startup and Candidate optional (capabilities :startup, :candidate)
•  Running may or may not be directly writable (:writable-running)
•  Need to copy from other stores if not directly writable

©2013 TAIL-F all rights reserved MAY 27, 2013 32

 Common Operations

Data Manipulation Locking

•  <get> ! •  <lock>!
•  <get-config>! •  <unlock>!
•  <edit-config>! !
•  <copy-config>! Transaction Management
•  <delete-config>! •  <commit> (:candidate, :confirmed)
•  <discard-changes> (:candidate)! •  <cancel-commit> (:confirmed)
!
Session Management Schema Management
•  <close-session>! •  <get-schema> (:monitoring)!
•  <kill-session>!
RPC Extensions
•  <rpc>!

May 11, 2014 ©2013 TAIL F all rights reserved 33

 Anatomy of NETCONF Sessions

Ambitious version: Short version:

•  Hello exchange including capabilities •  Hello exchange including capabilities
•  Lock running •  Edit config on running database
•  Lock candidate
•  Discard changes on candidate
•  Edit config on candidate
•  Commit confirmed (with timeout)
•  Confirm commit
•  Copy running to startup
•  Unlock candidate
•  Unlock running

May 11, 2014 ©2013 TAIL F all rights reserved 34

 Distributed Transactions (for Bonus Points)

1.  Connect to and lock R1, R2, R3

2.  Edit candidate databases and commit
with timeout
3.  (Optionally) do assurance checks
Management   during timeout
System   4.  Confirm commit, copy to startup and
release locks

Transaction context manager simply kills

all sessions on communication failure,
failed commits -> Rollback

R1   R2   R3  

May 11, 2014 ©2013 TAIL F all rights reserved 35

TUTORIAL: NETCONF AND YANG

NETCONF Example Configuration Sequence

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="5">!
<edit-config xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">!
<target>!
<candidate/>!
</target>!
<test-option>test-then-set</test-option>!
<error-option>rollback-on-error</error-option>!
<config>!
<interface xmlns=”urn:ietf:params:xml:ns:yang:ietf-interfaces">!
<name>eth1</name>!
<ipv4-address>192.168.5.10</ipv4-address>!
<macaddr>aa:bb:cc:dd:ee:ff</macaddr>!
</interface>! <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"!
message-id="5">!
</config>!
<ok/>!
</edit-config>!
</rpc-reply>!
</rpc>!
!
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="6">!
<validate>!
<source>! <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"!
<candidate/>! message-id="6">!
</source>! <ok/>!
</validate>! </rpc-reply>!
</rpc>!
!
<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="7">!
<commit>!
<confirmed/>!
</commit>! <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"!
</rpc>! message-id=“7">!
<ok/>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 36

TUTORIAL: NETCONF AND YANG

NETCONF RFC6241 Optional Capabilities

:writable-running!
:candidate!
:confirmed-commit!
:rollback-on-error!
:validate!
:startup!
:url (scheme=http, ftp, file, …)
:xpath (filters)

©2013 TAIL-F all rights reserved MAY 27, 2013 37

TUTORIAL: NETCONF AND YANG

Non-base NETCONF Capabilities

:notification, :interleave (RFC 5277)

:partial-lock (RFC 5717)
:with-defaults (RFC 6243)
:ietf-netconf-monitoring (RFC 6022)

And you can define your own, like

:actions (tail-f)
:inactive (tail-f)

©2013 TAIL-F all rights reserved MAY 27, 2013 38

TUTORIAL: NETCONF AND YANG

NETCONF Operations

©2013 TAIL-F all rights reserved MAY 27, 2013 39

TUTORIAL: NETCONF AND YANG

NETCONF <hello> Operation

•  Capabilities exchange •  Encoding

•  Data model ID exchange •  Framing
•  NETCONF 1.0 EOM, ]]>]]>
•  NETCONF 1.1 Chunk Framing

<?xml version="1.0" encoding="UTF-8"?>!

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!
<capabilities>!
<capability>urn:ietf:params:netconf:base:1.1</capability>!
</capabilities>!
</hello>!

©2013 TAIL-F all rights reserved MAY 27, 2013 40

TUTORIAL: NETCONF AND YANG

NETCONF <hello> Operation

<?xml version="1.0" encoding="UTF-8"?>!

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!
<capabilities>!
<capability>urn:ietf:params:netconf:base:1.1</capability>!
<capability>urn:ietf:params:netconf:capability:writable-running:1.0</capability!
<capability>urn:ietf:params:netconf:capability:candidate:1.0</capability>!
<capability>urn:ietf:params:netconf:capability:confirmed-commit:1.0</capability!
<capability>urn:ietf:params:netconf:capability:xpath:1.0</capability>!
<capability>urn:ietf:params:netconf:capability:validate:1.0</capability>!
<capability>urn:ietf:params:netconf:capability:rollback-on-error:1.0</capabilit!
<capability>http://tail-f.com/ns/netconf/with-defaults/1.0</capability>!
<capability>http://tail-f.com/ns/netconf/actions/1.0</capability>!
<capability>http://tail-f.com/ns/netconf/commit/1.0</capability>!
<capability>http://tail-f.com/ns/example/dhcpd?module=dhcpd</capability>!
<capability>urn:ietf:params:xml:ns:yang:ietf-inet-types?
revision=2010-09-24&amp;module=ietf-inet-types</capability>!
</capabilities>!
<session-id>5</session-id>

</hello>!

©2013 TAIL-F all rights reserved MAY 27, 2013 41

TUTORIAL: NETCONF AND YANG

NETCONF <get-config> Operation

•  Sub-tree filtering •  XPATH filtering

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="1">!

<get-config>!
<source>!
<running/>!
</source>!
<filter xmlns="http://tail-f.com/ns/aaa/1.1">!
<aaa/>!
</filter>!
</get-config>!
</rpc>!

©2013 TAIL-F all rights reserved MAY 27, 2013 42

TUTORIAL: NETCONF AND YANG

NETCONF <get-config> Operation

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-
id="1">!
<data>!
<aaa xmlns="http://tail-f.com/ns/aaa/1.1">!
<authentication>!
<users>!
<user>!
<name>admin</name>!
<uid>9000</uid>!
<gid>0</gid>!
<password>$1$3ZHhR6Ow$acznsyClFc0keo3B3BVjx/</password>!
<ssh_keydir>/var/confd/homes/admin/.ssh</ssh_keydir>!
<homedir>/var/confd/homes/admin</homedir>!
</user>!
<user>!
<name>oper</name>!
…!
</users>!
</authentication>!
</aaa>!
</data>!
</rpc-reply>!
©2013 TAIL-F all rights reserved MAY 27, 2013 43
TUTORIAL: NETCONF AND YANG

NETCONF <edit-config> Operation

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.1” message-id="1">!

<edit-config>!
<target><running/></target>!
<config>!
<dhcp xmlns="http://tail-f.com/ns/example/dhcpd"!
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1">!
<defaultLeaseTime nc:operation="merge”>PT1H

</defaultLeaseTime>!
</dhcp>!
</config>!
</edit-config>!
</rpc>!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1" message-

id="1">!
<ok/>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 44

TUTORIAL: NETCONF AND YANG

NETCONF <edit-config> Operation

Error if item exists
nc:test-option (:validate)! nc:operation!
test-then-set (default) merge!
set! replace!
test-only! create! Error if item to delete
does not exist
nc:error-option! delete !
stop-on-error (default) remove (:base:1.1)!
continue-on-error!
rollback-on-error 

(:rollback-on-error)!

Ok if item to delete does not

url  can  be  used  instead  of   exist
inline  config    (:url  capability)  

©2013 TAIL-F all rights reserved MAY 27, 2013 45

TUTORIAL: NETCONF AND YANG

NETCONF <copy-config> Operation

•  Copy and replace configuration data between stores or URLs

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:

1.1">!
<copy-config>!
<target><running/></target>!
<source>!
<url>https://[email protected]:passphrase/cfg/new.txt

</url>!
</source>!
</copy-config>!
</rpc>!

<rpc-reply message-id="101”
xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!
<ok/>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 46

TUTORIAL: NETCONF AND YANG

NETCONF <delete-config> Operation

•  Delete a complete data store (not running)

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:

1.1">!
<delete-config>!
<target>!
<startup/>!
</target>!
</delete-config>!
</rpc>!

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!

<ok/>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 47

TUTORIAL: NETCONF AND YANG

NETCONF <lock>, <unlock> Operation

•  Lock/unlock a complete data store

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!

<lock>!
<target>!
<candidate/>!
</target>!
</lock>!
</rpc>!

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:

1.1">!
<ok/>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 48

TUTORIAL: NETCONF AND YANG

NETCONF <get> Operation

•  Read configuration and status

<rpc message-id="101” xmlns=”urn:ietf:param
 <rpc-reply message-id="101” xmlns=“urn:ie!

<get>! <data>!
<filter type="subtree">! <top xmlns="http://example.com/ns/dhc

<top xmlns="http://example.com/ns/dhc
 <interfaces>!
<interfaces>! <interface>!
<interface>! <ifName>eth0</ifName>!
<ifName>eth0</ifName>! <ifInOctets>45621</ifInOctets>!
</interface>! <ifOutOctets>774344</ifOutOctet!
</interfaces>! </interface>!
</top>! </interfaces>!
</filter>! </top>!
</get>! </data>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 49

TUTORIAL: NETCONF AND YANG

NETCONF <close-session> Operation

•  Polite way of disconnecting

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!

<close-session/>!
</rpc>!

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:

1.1">!
<ok/>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 50

TUTORIAL: NETCONF AND YANG

NETCONF <kill-session> Operation

•  Not so polite way of disconnecting another session

Releases any locks, aborts any confirmed commit related to session

<rpc message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!

<kill-session>!
<session-id>17</session-id>!
</kill-session>!
</rpc>!

<rpc-reply message-id="101” xmlns="urn:ietf:params:xml:ns:netconf:base:

1.1">!
<ok/>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 51

TUTORIAL: NETCONF AND YANG

NETCONF capabilities

•  :writable-running!
•  <edit-config> and <copy-config> can have candidate as a
<target>!
•  :candidate!
•  Share “scratch-pad”!
•  <commit> to running!
•  <discard-changes>!
•  :confirmed-commit!
•  <confirmed> parameter to commit!
•  <cancel-commit>!
•  :validate!
•  <validate>!
•  <test-option> parameter to the <edit-config>!
•  :startup!
•  :url!
•  :xpath!
©2013 TAIL-F all rights reserved MAY 27, 2013 52
TUTORIAL: NETCONF AND YANG

NETCONF <partial-lock> Operation

•  Lock parts of the configuration in the running store

<nc:rpc xmlns=”…partial-lock”! <nc:rpc-reply xmlns:nc=“…net”!

xmlns:nc=“…netconf”! xmlns=”…partial-lock”!
message-id=”135”>! message-id="135">!
<partial-lock>! <lock-id>127</lock-id>!
<select xmlns:rte=“…”>
 <locked-node xmlns:rte=”…”!
/rte:routing/rte:virtualRouter
 /rte:routing/rte:virtualRouter

[rte:routerName='router1']! [rte:routerName='router1']!
</select>! </locked-node>!
<select xmlns:if=“…”>! <locked-node xmlns:if=”…”!
if:interfaces/
 /if:interfaces/

if:interface[if:id='eth1']! if:interface[if:id='eth1']!
</select>! </locked-node>!
</partial-lock>! </nc:rpc-reply>!
</nc:rpc>!
!
!

©2013 TAIL-F all rights reserved MAY 27, 2013 53

TUTORIAL: NETCONF AND YANG

NETCONF FILTERS

©2013 TAIL-F all rights reserved MAY 27, 2013 54

TUTORIAL: NETCONF AND YANG

NETCONF Filters

•  Namespace Selection
•  Containment Nodes
•  Selection Nodes
•  Content Match Nodes
•  Attribute Match Expression
•  XPATH (capability)

©2013 TAIL-F all rights reserved MAY 27, 2013 55

TUTORIAL: NETCONF AND YANG

NETCONF Filters: Namespace selection

<filter  type="subtree">  
       <top  xmlns="hcp://example.com/schema/1.2/config"/>  
 </filter>  

Selec5on  
Node  
An  empty  leaf  node  within  a  filter  
<top/>  
<top></top>  

©2013 TAIL-F all rights reserved MAY 27, 2013 56

TUTORIAL: NETCONF AND YANG

NETCONF Filters: Containment

<filter  type="subtree">  
   <top  xmlns="hcp://example.com/schema/1.2/config">  
           <users/>  
   </top>  
</filter>  

©2013 TAIL-F all rights reserved MAY 27, 2013 57

TUTORIAL: NETCONF AND YANG

NETCONF Filters: Content Match

<filter  type="subtree">  
             <top  xmlns="hcp://example.com/schema/1.2/config">  
                 <users>  
                     <user>  
                         <name>fred</name>  
                     </user>  
                 </users>  
             </top>  
         </filter>  

©2013 TAIL-F all rights reserved MAY 27, 2013 58

TUTORIAL: NETCONF AND YANG

NETCONF Filters: Attribute Match

Containment  
Nodes  
<filter  type="subtree">  
             <t:top  xmlns:t="hcp://example.com/schema/1.2/config">  
                 <t:interfaces>  
                     <t:interface  t:ifName="eth0"/>  
                 </t:interfaces>  
             </t:top>  
         </filter>  
XML  Acribute….  

Selec5on  
Node  

©2013 TAIL-F all rights reserved MAY 27, 2013 59

TUTORIAL: NETCONF AND YANG

NOTIFICATIONS

©2013 TAIL-F all rights reserved MAY 27, 2013 60

TUTORIAL: NETCONF AND YANG

Event Notifications

•  What is right for you? •  NETCONF

•  SNMP Traps over UDP •  Requires open connection
•  SYSLOG Messages over UDP •  Supports replay
•  NETCONF Notifications over SSH •  SNMP
•  Define your own
•  Much used, works ok
•  Limited payload
•  Connection-less
•  SYSLOG
•  Lacks standard format
! www.rfc-editor.org/rfc/rfc5277.txt

©2013 TAIL-F all rights reserved MAY 27, 2013 61

TUTORIAL: NETCONF AND YANG

Example:
VPN provisioning using NETCONF
Network-wide Transactions

©2013 TAIL-F all rights reserved MAY 27, 2013 62

TUTORIAL: NETCONF AND YANG

VPN Scenario

•  An operator owns a network of routers

and other equipment from different
vendors
•  They have a management station
Site  A   connected to all the devices in the
network to provision and monitor
North
services
•  Now, we need to set up a VPN
between two customer sites
•  There is no point what so ever to
make any changes on any device
Site  B   unless all changes succeed
•  We need a Network-wide Transaction
East

West

©2013 TAIL-F all rights reserved MAY 27, 2013 63

TUTORIAL: NETCONF AND YANG

Hello Site  A  
North

•  Exchange capabilities

Site  B  
>>>>> Router-West (Sun Nov 15 14:41:25 CET 2009)!
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">! East
<capabilities>!
<capability>urn:ietf:params:netconf:base:1.1</capability>!
</capabilities>! West
</hello>!

<<<< Router-West (Sun Nov 15 14:41:25 CET 2009)!

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!
<capabilities>!
<capability>urn:ietf:params:netconf:base:1.1</capability>!
<capability>http://tail-f.com/ns/netconf/actions/1.0</capability>!
<capability>http://tail-f.com/ns/aaa/1.1</capability>!
<capability>http://tail-f.com/ns/example/quagga/1.0</capability>!
</capabilities>!
<session-id>4</session-id>!
</hello>!

©2013 TAIL-F all rights reserved MAY 27, 2013 64

TUTORIAL: NETCONF AND YANG

Lock the candidate data stores

>>>>> Router-West (Sun Nov 15 15:24:33 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="2">!
<nc:lock>!
<nc:target>!
<nc:candidate></nc:candidate>!
</nc:target>!
</nc:lock>!
</nc:rpc>!

<<<< Router-West (Sun Nov 15 15:24:33 CET 2009)!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="2">!
<ok></ok>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 65

TUTORIAL: NETCONF AND YANG

Lock the running data stores

>>>>> Router-West (Sun Nov 15 15:24:33 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="3">!
<nc:lock>!
<nc:target>!
<nc:running></nc:running> !
</nc:target>!
</nc:lock>!
</nc:rpc>!

<<<< Router-West (Sun Nov 15 15:24:33 CET 2009)!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="3">!
<ok></ok>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 66

TUTORIAL: NETCONF AND YANG

Clear the candidate data stores

>>>>> Router-West (Sun Nov 15 15:24:32 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="1">!
<nc:discard-changes></nc:discard-changes>!
</nc:rpc>!

<<<< Router-West (Sun Nov 15 15:24:33 CET 2009)!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="1">!
<ok></ok>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 67

TUTORIAL: NETCONF AND YANG

Edit the candidates

>>>>> Router-West (Sun Nov 15 15:24:33 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="5">!
<nc:edit-config>!
<nc:target><nc:candidate></nc:candidate></nc:target>!
<nc:config>!
<quagga:system xmlns:quagga="http://tail-f.com/ns/example/quagga!
<quagga:vpn>!
<quagga:ipsec>!
<quagga:tunnel>!
<quagga:name>volvo-0</quagga:name>!
<quagga:local-endpoint>10.7.7.4</quagga:local-endpoint>!
<quagga:local-net>33.44.55.0</quagga:local-net>!
<quagga:local-net-mask>255.255.255.0</quagga:local-net-mas!
<quagga:remote-endpoint>10.3.4.1</quagga:remote-endpoint>!
<quagga:remote-net>62.34.65.0</quagga:remote-net>!
<quagga:pre-shared-key>ford</quagga:pre-!
<quagga:encryption-algo>default!
<quagga:hash-algo>defau!

©2013 TAIL-F all rights reserved MAY 27, 2013 68

TUTORIAL: NETCONF AND YANG

Validate candidates

>>>>> Router-West (Sun Nov 15 15:24:33 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="6">!
<nc:validate>!
<nc:source>!
<nc:candidate></nc:candidate>!
</nc:source>!
</nc:validate>!
</nc:rpc>!

<<<< Router-West (Sun Nov 15 15:24:33 CET 2009)!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="6">!
<ok></ok>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 69

TUTORIAL: NETCONF AND YANG

Commit candidates to running

>>>>> Router-West (Sun Nov 15 15:24:33 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="7">!
<nc:commit></nc:commit>!
</nc:rpc>!

<<<< Router-West (Sun Nov 15 15:24:33 CET 2009)!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="7">!
<ok></ok>!
</rpc-reply>!

Confidential Information | May 11, 2014

©2013 TAIL-F all rights reserved MAY 27, 2013 70
TUTORIAL: NETCONF AND YANG

Unlock candidates

>>>>> Router-West (Sun Nov 15 15:24:33 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="8">!
<nc:unlock>!
<nc:target>!
<nc:candidate></nc:candidate>!
</nc:target>!
</nc:unlock>!
</nc:rpc>!

<<<< Router-West (Sun Nov 15 15:24:33 CET 2009)!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="8">!
<ok></ok>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 71

TUTORIAL: NETCONF AND YANG

Using confirmed-commit

•  Now do the same thing again, but instead of commit…

>>>>> Router-West (Sun Nov 15 15:29:19 CET 2009)!

<nc:rpc xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" nc:message-id="16">!
<nc:commit>!
<nc:confirmed></nc:confirmed>!
<nc:confirm-timeout>120</nc:confirm-timeout>!
</nc:commit>!
</nc:rpc>!

<<<< Router-West (Sun Nov 15 15:29:19 CET 2009)!

<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.1"
xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.1" message-id="16">!
<ok></ok>!
</rpc-reply>!

©2013 TAIL-F all rights reserved MAY 27, 2013 72

TUTORIAL: NETCONF AND YANG

Disaster happens

•  One of the devices disconnected

•  The management station disconnects all the rest
•  They all roll back to the previous configuration
•  The management station reconnects

>>>>> Router-West (Sun Nov 15 15:30:22 CET 2009)!

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!
<capabilities>!
<capability>urn:ietf:params:netconf:base:1.1</capability>!
</capabilities>!
</hello>!

<<<< Router-West (Sun Nov 15 15:30:22 CET 2009)!

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.1">!
<capabilities>!
<capability>urn:ietf:params:netconf:base:1.1</capability>!
<capability>urn:ietf:params:netconf:capability:writable-running:1.!

©2013 TAIL-F all rights reserved MAY 27, 2013 73

TUTORIAL: NETCONF AND YANG

Common NETCONF Use Cases

•  Network-wide transactions
•  Applying and testing a configuration
•  Testing and rejecting a configuration
•  Rollback when device goes down
•  Transactions requiring all devices to be up
•  Backlogging transactions
•  Synchronizing

©2013 TAIL-F all rights reserved MAY 27, 2013 74

TUTORIAL: NETCONF AND YANG

YANG Overview and Examples

©2013 TAIL-F all rights reserved MAY 27, 2013 75

TUTORIAL: NETCONF AND YANG

YANG ?

acme-­‐box  module  
•  Data modeling language
•  Configuration data
•  State data proper5es  container  
•  Tree structure
•  Close to device name:  string,  config  
•  Managing device features
•  Data and Types
•  Constraints interfaces  container  
•  Augmentation
•  Reusable structures interface:  list,  index  =  name  
•  Extensions
•  SMI translation name:  string,  config  
•  XML
•  NETCONF Transport Encoding oper-­‐state:  enum,  config  
•  YANG – XML Model mapping

©2013 TAIL-F all rights reserved MAY 27, 2013 76

TUTORIAL: NETCONF AND YANG

YANG ?

©2013 TAIL-F all rights reserved MAY 27, 2013 77

TUTORIAL: NETCONF AND YANG

YANG Module Contents

Header information

Imports & Includes

Type definitions

Configuration & Operational

data declarations

Action (RPC) & Notification declarations

©2013 TAIL-F all rights reserved MAY 27, 2013 78

TUTORIAL: NETCONF AND YANG

YANG Header

URI  

©2013 TAIL-F all rights reserved MAY 27, 2013 79

TUTORIAL: NETCONF AND YANG

YANG Data Definitions

©2013 TAIL-F all rights reserved MAY 27, 2013 80

TUTORIAL: NETCONF AND YANG

Data Modeling Nodes

•  Leaf
•  Leaf-List
•  Container
•  List

©2013 TAIL-F all rights reserved MAY 27, 2013 81

TUTORIAL: NETCONF AND YANG

Leaf Statement

Holds a single value of a particular

host-name
type
Has no children cpu-temp

leaf host-name {!
type string;!
mandatory true;! NETCONF XML:
config true;! <host-name>my.example.com</host-name>
description "Hostname for this system";!
}!
leaf cpu-temp {!
type int32;!
units degrees-celsius;!
config false;!
description ”Current temperature in CPU";!
}! cpu-­‐temp  not  returned  in  
! NETCONF  get-­‐config  

©2013 TAIL-F all rights reserved MAY 27, 2013 82

TUTORIAL: NETCONF AND YANG

Attributes for leaf

config! Whether this leaf is a configurable value (“true”) or

operational value (“false”). Inherited from parent container
if not specified
default! Specifies default value for this leaf. Implies that leaf is
optional
mandatory! Whether the leaf is mandatory (“true”) or optional (“false”)

must! XPath constraint that will be enforced for this leaf

type! The data type (and range etc) of this leaf

when! Conditional leaf, only present if XPath expression is true
descripti Human readable definition and help text for this leaf
on!
reference! Human readable reference to some other element or spec
units! Human readable unit specification (e.g. Hz, MB/s, ℉)
status! Whether this leaf is “current”, “deprecated” or “obsolete”
©2013 TAIL-F all rights reserved MAY 27, 2013 83
TUTORIAL: NETCONF AND YANG

Leaf-list Statement

Holds multiple values of a particular domain-search

type
Has no children

leaf-list domain-search {!
type string;!
ordered-by user;!
description "List of domain names to search";!
}!

NETCONF operations to insert NETCONF XML:

<domain-search>high.example.com</domain-search>
first, last, before, after <domain-search>low.example.com</domain-search>

©2013 TAIL-F all rights reserved MAY 27, 2013 84

TUTORIAL: NETCONF AND YANG

Container Statement

Groups related leafs and containers system

services

ssh
Presence
container system {!
…
container services {!
container ssh {! …
presence "Enables SSH";!
description "SSH service specific configuration";!
// more leafs, containers and other things here...!
}!
}!
}!
NETCONF XML:
<system>
<services>
<ssh>
Presence  containers  explicitly  created/deleted  by   </ssh>
NETCONF  client.  They  also  represent  config  “themselves”.   </services>
“Normal”  containers  have  no  meaning,  just  organiza5on  of   </system>
data.  

©2013 TAIL-F all rights reserved MAY 27, 2013 85

TUTORIAL: NETCONF AND YANG

List Statement

user

name uid full-name class

Default

list user {! leaf full-name {! NETCONF XML:

key name;! type string;! <user>
leaf name {! }! <name>glocks</name>
type string;! leaf class {! …
}! type string;! </user>
leaf uid {! default viewer;! <user>
<name>snowey</name>
type uint32;! }! …
}! }! </user>
!

NETCONF operations to insert

Non-­‐config  lists  can  skip  key   first, last, before, after
Given  at  create!  
©2013 TAIL-F all rights reserved MAY 27, 2013 86
TUTORIAL: NETCONF AND YANG

Putting things together

©2013 TAIL-F all rights reserved MAY 27, 2013 87

TUTORIAL: NETCONF AND YANG

Attributes for list and leaf-list

max- Max number of elements in list. If max-elements is not

elements! specified, there is no upper limit, i.e. “unbounded”
min- Min number of elements in list. If min-elements is not
elements! specified, there is no lower limit, i.e. 0
ordered- List entries are sorted by “system” or “user”. System means
by! elements are sorted in a natural order (numerically,
alphabetically, etc). User means the order the operator
entered them in is preserved.
“ordered-by user” is meaningful when the order among the
elements have significance, e.g. DNS server search order or
firewall rules.

©2013 TAIL-F all rights reserved MAY 27, 2013 88

TUTORIAL: NETCONF AND YANG

Keys

user

name uid full-name class

Default  

yang 1010 Yan Goode admin

hawk 1152 Ron Hawk oper
ling 1202 Lin Grossman viewer

/user[name=‘yang’]/name = yang!
The key field is used to specify /user[name=‘yang’]/uid = 1010!
which row we’re talking about. /user[name=‘yang’]/class = admin!
!
No two rows can have same key /user[name=‘ling’]/class = viewer!

value

©2013 TAIL-F all rights reserved MAY 27, 2013 89

TUTORIAL: NETCONF AND YANG

Keys

user

uid name full-name class

Default

1010 yang Yan Goode admin

1152 hawk Ron Hawk oper
1202 ling Lin Grossman viewer

If we want, we could select the /user[uid=‘1010’]/name = yang!

uid to be key instead. /user[uid=‘1010’]/uid = 1010!
/user[uid=‘1010’]/class = admin!
!
/user[uid=‘1202’]/class = viewer!
!

©2013 TAIL-F all rights reserved MAY 27, 2013 90

TUTORIAL: NETCONF AND YANG

Unique Statement

user

uid name full-name class

Default

1010 yang Yan Goode admin

1152 hawk Ron Hawk oper
1202 ling Lin Grossman viewer

Non- key fields can also be list user {!

key uid;!
declared unique. unique name;!
…!
Multiple fields can be declared !
unique separately or in No two rows above can have
combination same uid, nor name
!

©2013 TAIL-F all rights reserved MAY 27, 2013 91

TUTORIAL: NETCONF AND YANG

Multiple keys

route

ip prefix next-hop metric

Default

16.40.0. 16 220.40.0.1 20
0
16.42.0. 16 82.193.16.1 40
0
16.42.0. 24 82.193.16.6 50
0

Multiple key fields are list route {!

key “ip prefix”;!
needed when a single key …!
field isn’t unique. !
/route[ip=‘16.40.0.0’][prefix=’16’]/next-
Key fields must be a unique hop

= 220.40.0.1!
combination !
Key order significant

©2013 TAIL-F all rights reserved MAY 27, 2013 92

TUTORIAL: NETCONF AND YANG

Leafref

To make an element reference one of •  A valid leafref can never be

the rows in a list, set the element type
to leafref null/empty
–  But the parent leaf can be
optional
For lists with multiple keys, the #leafrefs
must match #keys in list •  A valid leafref can never
point to a row that has
been deleted or renamed
•  System checks validity of
leafrefs automatically

©2013 TAIL-F all rights reserved MAY 27, 2013 93

TUTORIAL: NETCONF AND YANG

Leafref

interface rip

name address network-ifname

0 .. 64

eth0.16 ifname
eth0.19 192.168.0.1 eth0.19
eth2.5 24.97.238.15

Here, the RIP routing container rip {!

list network-ifname {!
subsystem has a list of key ifname;!
leafrefs pointing out existing !
interfaces leaf ifname {!
type leafref {!
path “/interface/name”;!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 94

TUTORIAL: NETCONF AND YANG

Multiple Key Leafref

client video

ip port v-ip v-port

12.36.2.19 33115
12.36.2.19 33667 12.36.2.19 33667

67.3.51.196 33667

container video {!
leaf v-ip { !
type leafref { !
path "/client/ip"; !
}!
}!
leaf v-port { !
type leafref { !
path "/client[ip=current()/../v-ip]/port";!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 95

TUTORIAL: NETCONF AND YANG

Deref() XPATH Operator

container video {! container video-deref {!

leaf v-ip { ! leaf v-ip { !
type leafref { ! type leafref { !
path "/client/ip"; ! path "/client/ip"; !
}! }!
}! }!
leaf v-port { ! leaf v-port { !
type leafref { ! type leafref { !
path "/client! path "deref(../v-ip)

[ip=current()/../v-ip]/port"; ! /../port”;!
}! }!
}! }!
leaf v-stream { ! leaf v-stream { !
type leafref { ! type leafref { !
path "/client! path "deref(../v-port)

[ip=current()/../v-ip]
 /../stream"; !
[port=current()/../v-port]
 !
/stream"; ! !
}! }

}! }!
}! }!

©2013 TAIL-F all rights reserved MAY 27, 2013 96

TUTORIAL: NETCONF AND YANG

Grouping Statement

Think “macro expansion”

target
grouping target {!
leaf address {!
type inet:ip-address;! address
description "Target IP";! port
}!
leaf port {!
peer
type inet:port-number;!
description 
 destination
"Target port number";!
}! address
}!
container peer {! port
container destination {!
uses target;!
}!
}!
Groupings  can  be  
refined  when  used  

©2013 TAIL-F all rights reserved MAY 27, 2013 97

TUTORIAL: NETCONF AND YANG

Grouping Statement with Refine

Groupings may be refined when used

grouping target {! container servers {!

leaf address {! container http {!
type inet:ip-address;! uses target {!
description "Target IP";! refine port {!
}! default 80;!
leaf port {! }!
type inet:port-number;! }!
description 
 }!
"Target port number";! }!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 98

TUTORIAL: NETCONF AND YANG

IMPORT AND INCLUDE

©2013 TAIL-F all rights reserved MAY 27, 2013 99

TUTORIAL: NETCONF AND YANG

Imports & Includes

Module X Namespace Module Y Namespace

Fragment import
A.yang

include
Fragment
E.yang
Fragment
B.yang
Imported fragments are just
include include referenced, not included

Fragment Fragment
C.yang D.yang

Each included fragment is a

complete YANG file; can never
be included in any other
module/namespace

©2013 TAIL-F all rights reserved MAY 27, 2013 100

TUTORIAL: NETCONF AND YANG

Each submodule belongs to one

specific main module
Submodules

module acme-module {! submodule acme-system {!

namespace “…”;! belongs-to acme-module {!
prefix acme;! prefix acme;!
! }!
import ”ietf-yang-types" {! !
prefix yang;! import ”ietf-yang-types" {!
}! prefix yang;!
include "acme-system";! }!
! !
container system {!
…!
}!
}!

Attention: The submodule cannot

reference definitions in main module

©2013 TAIL-F all rights reserved MAY 27, 2013 101

TUTORIAL: NETCONF AND YANG

YANG Types

©2013 TAIL-F all rights reserved MAY 27, 2013 102

TUTORIAL: NETCONF AND YANG

YANG Base Types

•  Most YANG elements have a Type Name Meaning

data type
int8/16/32/64! Integer
•  Type may be a base type or
derived type uint8/16/32/64! Unsigned integer
•  Derived types may be simple
typedefs or groupings decimal64! Non-integer
(structures)
string! Unicode string
•  There are 20+ base types to
start with enumeration! Set of
•  And more in modules like alternatives
•  ietf-yang-types, RFC 6021 boolean! True or false
bits! Boolean array
binary! Binary BLOB
leafref! Reference
“pointer”
identityref! Unique identity
empty! No value, void
©2013 TAIL-F all rights reserved …and more MAY 27, 2013 103
TUTORIAL: NETCONF AND YANG

Typedef Statement

Defines a new simple type

typedef percent {! percent

type uint16 {!
range "0 .. 100";!
}!
description "Percentage";! completed
}!
!
leaf completed {!
type percent;!
}!

Can  be  scoped  

©2013 TAIL-F all rights reserved MAY 27, 2013 104

TUTORIAL: NETCONF AND YANG

Type Restrictions

Integers Strings
typedef my-base-int32-type {! typedef my-base-str-type {!
type int32 {! type string {!
range "1..4 | 10..20";! length "1..255";!
}! }!
}! }!
! !
typedef derived-int32 {! typedef derived-str {!
type my-base-int32-type {! type my-base-str-type {!
range "11..max"; // 11..20! length "11 | 42..max"; 

}! pattern "[0-9a-fA-F]*";!
} ! }!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 105

TUTORIAL: NETCONF AND YANG

Union Statement

A value that represents one of its member types!

typedef threshold {!
description ”Threshold value in percent";!
type union {!
type uint16 {!
range "0 .. 100";!
}!
type enumeration {!
enum disabled {!
description "No threshold";!
}!
}!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 106

TUTORIAL: NETCONF AND YANG

Common YANG Types

•  Commonly used counter32/64! ipv4-address!

YANG types defined
in RFC 6021 gauge32/64! ipv6-address!
•  Use object- ip-prefix!
import “ietf-yang-types” {
 identifier!
prefix yang;

date-and-time! ipv4-prefix!
}
to reference these timeticks! ipv6-prefix!
types as e.g.

type yang:counter64; timestamp! domain-name!
phys-address! uri!
ip-version! mac-address!
flow-label! bridgeid!
port-number! vlanid!
ip-address! … and more
! www.rfc-editor.org/rfc/rfc6021.txt
 
©2013 TAIL-F all rights reserved MAY 27, 2013 107
TUTORIAL: NETCONF AND YANG

YANG RPCs & Notifications

©2013 TAIL-F all rights reserved MAY 27, 2013 108

TUTORIAL: NETCONF AND YANG

RPC Statement

Administrative actions with input

and output parameters
activate-software-image

image
rpc activate-software-image {!
input {! status
leaf image {!
type binary;!
}!
}!
output {!
leaf status {!
type string;!
}!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 109

TUTORIAL: NETCONF AND YANG

Notification Statement

Notification with output parameters

config-­‐change  
notification config-change {!
description ! operator-­‐name  
”The configuration changed";!
leaf operator-name {! change  
type string;!
}!
leaf-list change {!
type instance-identifier;!
}!
}!

Instance-identifier values

<change>/ex:system/ex:services/ex:ssh/ex:port</change>!
<change>/ex:system/ex:user[ex:name='fred']/ex:type</change>!
<change>/ex:system/ex:server[ex:ip='192.0.2.1'][ex:port='80’]</change>!

©2013 TAIL-F all rights reserved MAY 27, 2013 110

TUTORIAL: NETCONF AND YANG

Advanced YANG Statements

©2013 TAIL-F all rights reserved MAY 27, 2013 111

TUTORIAL: NETCONF AND YANG

Must Statement

Restricts valid values by Xpath 1.0 expression

container timeout {!
leaf access-timeout {!
description "Maximum time without server response";!
units seconds;!
mandatory true;!
type uint32;!
}!
leaf retry-timer {!
description "Period to retry operation";!
units seconds;!
type uint32;!
must ”current() < ../access-timeout" {!
error-app-tag retry-timer-invalid;!
error-message "The retry timer must be "!
+ "less than the access timeout";!
}!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 112

TUTORIAL: NETCONF AND YANG

Must Statement

leaf max-weight {!
type uint32 {!
range "0..1000";!
}!
default 100;!
!
must "sum(/sys:sys/interface[enabled = 'true']/weight) !
< current()" {!
!
error-message "The total weight exceeds the configured !
max weight";!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 113

TUTORIAL: NETCONF AND YANG

Augment Statement

user
+
name uid full-name class expire
Default

augment /sys:system/sys:user {!
leaf expire {!
type yang:date-and-time;!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 114

TUTORIAL: NETCONF AND YANG

When Statement

user
+
name uid full-name class expire shell
Default When

augment /sys:system/sys:user {!
when ”sys:class = ‘wheel’";!
leaf shell {!
type string;!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 115

TUTORIAL: NETCONF AND YANG

Choice Statement

Choice allows one of several

alternatives transfer-­‐method  

transfer-­‐interval  
choice transfer-method {!
leaf transfer-interval {! transfer-­‐on-­‐commit  
description "Frequency at which file transfer happens";!
type uint16 {!
range "15 .. 2880";!
}!
units minutes;!
}!
leaf transfer-on-commit {!
description "Transfer after each commit";!
type empty;!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 116

TUTORIAL: NETCONF AND YANG

Choice Statement

Each alternative may consist of multiple definitions

•  Either as a named or anonymous group

choice counters {!
case four-counters {!
leaf threshold {…}!
leaf ignore-count {…}!
leaf ignore-time {…}!
leaf reset-time {…}!
}! •  Only  in  schema  tree  
container warning-only {! •  Not  in  the  data  tree  or  NETCONF  
…! •  Device  handles  dele5on  of  “other”  
}! case  when  case  is  created.  
default four-counters;!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 117

TUTORIAL: NETCONF AND YANG

Identity Statement

Identities for modeling families of related enumeration constants

module phys-if {! module newer {!

…! …!
identity ethernet {! identity eth-40G {!
description ! base phys-if:ethernet;!
}! }!
identity eth-1G {! identity eth-100G {!
base ethernet;! base phys-if:ethernet;!
}! }!
identity eth-10G {! …!
base ethernet;! leaf eth-type {!
}! type identityref {!
base ”phys-if:ethernet";!
}!
}!
!

©2013 TAIL-F all rights reserved MAY 27, 2013 118

TUTORIAL: NETCONF AND YANG

Feature Statement

Mark data as conditional

feature has-local-disk {! system
description !
“System has a local file! logging
system that can be used! Feature, Presence
for storing log files”;! buffer-size
}!
!
container system {!
container logging {!
if-feature has-local-disk;!
presence “Logging enabled”;! The features supported by a system are
leaf buffer-size {! meant to stay relatively constant.
type filesize;! Adding a feature is comparable to a
}! hardware upgrade.
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 119

TUTORIAL: NETCONF AND YANG

Deviations

Systems should conform to standard Yang Modules

•  Still, if a device can’t, that can be properly declared

deviation /base:system/base:user/base:type {!
deviate add {!
default "admin"; // new users are 'admin' by default!
}!
}!
deviation /base:system/base:name-server {!
deviate replace {!
max-elements 3;!
}!
}!

©2013 TAIL-F all rights reserved MAY 27, 2013 120

TUTORIAL: NETCONF AND YANG

Current IETF Status

©2013 TAIL-F all rights reserved MAY 27, 2013 121

TUTORIAL: NETCONF AND YANG

IETF Activities

NETCONF Working Group NETMOD Working Group

•  Rechartering in progress •  Interface configuration
•  NETCONF over TLS •  IP address management
•  Reverse SSH •  Basic routing management
•  System management (i.e. MIB-II)
•  SNMP Configuration

Maybe: Maybe:
•  RESTCONF •  Topologies
•  DHCPv6 option for server discovery •  ACLs
•  Efficiency extensions •  OSPF

©2013 TAIL-F all rights reserved MAY 27, 2013 122

TUTORIAL: NETCONF AND YANG

NETCONF RFC Overview

•  RFC 3535 Informational: Background

•  RFC 6244 NETCONF+Yang Architectural Overview
•  RFC 6241 Base NETCONF Protocol
•  RFC 6242, 4743-4744, 5539 Transport Mappings
•  RFC 5277 Notifications
•  RFC 5717 Partial Locking
•  RFC 6243 With defaults
•  RFC 6470 Base Notifications
•  RFC 6536 NETCONF Access Control Model

! https://datatracker.ietf.org/wg/netconf/charter/
! www.rfc-editor.org/rfc/rfcXXXX.txt

©2013 TAIL-F all rights reserved MAY 27, 2013 123

TUTORIAL: NETCONF AND YANG

YANG RFC Overview

•  RFC 6020 YANG Base Specification

•  RFC 6021 YANG Types
•  RFC 6087 Guidelines for YANG Authors and Reviewers
•  RFC 6110 Mapping and Validating YANG
•  RFC 6244 NETCONF+Yang Architectural Overview
•  RFC 6643 Translation of SMIv2 MIBs to YANG

!  https://datatracker.ietf.org/wg/netmod/charter/
!  https://www.ietf.org/iesg/directorate/yang-doctors.html
!  http://www.yang-central.org/

©2013 TAIL-F all rights reserved MAY 27, 2013 124