Netconf/YANG tutorial

ENOG15 Moscow - June 2018

Evgeny Zobnitsev ( )
Agenda

•Orchestration problem statement

• Netconf overview
• Restconf overview
• Yang overview
• OpenDaylight overview
• DEMO

2
Network configuration management today
● Various proprietary CLIs of the network elements (NEs)
● Various proprietary APIs of the network elements and
controller
● Manual configuration or expect scripts, as automation
● Imperative, incremental NEs configuration, lack of
abstractions
● Configuration screen scraping from NEs, using parsing
− The most bad thing, no programmatic knowledge when
the CLI command finished.
− CLI designed to work with humans, not machines.
● SNMP - has not solved this problems (see RFC3535)
3
Network configuration management today
● Service lifecycle management - workflow-based
− Workflows describes to the provisioning system, in
detail, which steps to take to reach a final state.
− Each service livecycle action has to be explicitly
defined: service create, service change, service edit,
service delete.

4
Network application life cycle today

Add the caption here

5
Network configuration management today
● Model-driven topology of the network
− describes structure of the network.
● Model-driven services description, auto-generating APIs
− describes structure of the network services, APIs.
● Model-driven configuration of the network elements
(NEs)
− describes structure of network element configuration,
provided and supported by vendor.
● Model-driven telemetry of the network elements (NEs)
− describes structure of network element supported
telemetry, provided and supported by vendor.
6
Network application life cycle (End-to-End Model-Driven )

7
Comparison of Workflow-based and
Model-to-model service-to-network mapping

8
Agenda

• Orchestration problem statement

•Netconf overview
• Restconf overview
• Yang overview
• OpenDaylight overview
• DEMO

9
Key Features of NETCONF (RFC6241)
● Domain-Specific Knowledge
− NETCONF was specifically developed to support network configuration
● Support for Transactionality
− NETCONF support Atomicity, Consistency, Isolation, Durability (ACID)
transactionality
● Vendor Device Independence
− NETCONF has abilities to get capabilities just from device during <hello>
exchange
● Support of run RPCs to run actions
− NETCONF has abilities to run the RPC that device support
● Device versions built-in support
− NETCONF has abilities to run <get-schema> RPC, to download YANG
model of device configuration just from device itself

10
NETCONF Transport
NETCONF messages are encoded in XML
● Each message is framed by:
− NETCONF 1.0: a character sequence ]]>]]>
− NETCONF 1.1: a line with the number of characters to read in ASCII
● NETCONF messages are encrypted by SSH,SSH provides authentication,
integrity and confidentiality
● NETCONF is connected oriented using TCP
● When a NETCONF Manager connects to a NETCONF Server (NE), they send
<hello> message
● The contents of the <hello> message declares which NETCONF Capabilities
each party is capable of.
● By declaring support for a capability in <hello>, the manager will know which
operations it can submit to the NE.
● Extensions go in separate XML namespaces, which makes it easier to build
backwards and forwards compatible management applications
11
Agenda

• Orchestration problem statement

• Netconf overview
•Restconf overview
• Yang overview
• OpenDaylight overview
• DEMO

12
Key Features of RESTCONF (RFC 8040)
● uniform, standardized way for Web applications to access the
configuration data, state data, data-model-specific Remote Procedure
Call (RPC) operations, and event notifications within a network
element.
● operates on the configuration datastores defined in NETCONF and
defines a set of CRUD operations that can be used to access these
datastores.
● YANG language defined
● uses URI-encoded path expressions to identify the YANG data nodes
unlike NETCONF, that using XPath expressions, starting from the
document root to the target resource.
● operates on a hierarchy of resources are accessed via a set of URIs
using syntax specified in RFC 8040

13
 RESTCONF HTTP methods vs NETCONF
RESTCONF operation Description NETCONF operation
HEAD Get without a body <none>
OPTION Discover which operations are <none>
supported by a data resource
GET Retrieve data and metadata <get>, <get-config>

POST Create a data resource <edit-config>

(nc:operation=“create”)

POST Invoke an RPC operation Call RPC directly

14
RESTCONF HTTP methods vs NETCONF

RESTCONF operation Description NETCONF operation

PUT Create or replace a data resource <edit-config>
(nc:operation=“create/
replace”), <copy-config>
(PUT on datastore)

PATCH Create or update but not delete <edit-config>

(nc:operation depends
a data resource on patch content)

DELETE Delete a data resource <edit-config>

(nc:operation=“delete”)

15
Agenda

•Orchestration problem statement

• Netconf overview
• Restconf overview
•Yang overview
• OpenDaylight overview
• DEMO

16
 Key Features of Yang (RFC6020)
● Service & NE Data Models vs. Information Models (UML)
− Yang is the data modeling language
● Domain-Specific Language
− Yang was specifically developed to support network configuration
● NE configuration modeling
− Yang is rich enough to model NE configuration (often follow the CLI)
● Service configuration modeling
− Yang is rich enough to model services in the same language as the NE
● Network topology modeling
− Any new device can be supported, by publishing Yang
● Vendors must create and publish Yang models of their own devices via ietf-
netconf-monitoring RFC feature

17
 New Features of Yang (RFC7950)
YANG version 1.1 is a maintenance release of the YANG language, addressing
ambiguities and defects in the original specification [RFC6020].
Key changes (not all of them):
● A server advertises support for YANG 1.1 modules by using ietf-yang-library
[RFC7895] instead of listing them as capabilities in the <hello> message.
● Added a set of new XML Path Language (XPath) functions
● Allow "augment" to add conditionally mandatory nodes
● Allow imports of multiple revisions of a module
● Made the "yang-version" statement mandatory in YANG version "1.1”
● Allow "if-feature" in "bit", "enum", and "identity”
● Allow notifications to be tied to data nodes
● Added a new statement "action", which is used to define operations tied to data
nodes
● Allow notifications to be tied to data nodes

18
 Yang module definition example
module mplsl3vpn { list endpoint {
namespace "http://ru/fgts/mplsl3vpn"; leaf pe-device {
description "PE-device selection";
prefix mplsl3vpn;
mandatory true;
import ietf-inet-types { type leafref {
prefix inet; path "/system:devices/system:device\
} /system:name";
import junos { }
prefix junos; }
container interfaces {
}
description "Interface parameters on the PE-device";
include "ietf-bgp-l3vpn"; leaf interface {
organization "Factor Group"; type leafref {
contact e@zobnitsev.ru; path deref(../../pe-device)/../system:config/
description "This is MPLS L3VPN junos:configuration/junos\
service for FGTS Lab"; :interfaces/junos:interface/junos:name;
revision 2014-02-20 { }
}
description "Initial revision.";
}
}

19
 Protocols interaction & standardization

* Source - Benoît Claise blog: http://www.claise.be/2016/12/yang-opensource-tools-for-

data-modeling-driven-management/
20
 Extracting Yang modules out from RFCs
● To extract the Yang module(s) out of IETF draft for ez@eztp pyang -p NSO/ncs/src/ncs/yang -p NSO/run-ncs/packages/ -f
tree NSO/run-ncs/packages/mplsl3vpn/src/yang/mplsl3vpn.yang

the validation, Jan Medved created the xym.py, module: mplsl3vpn

augment /ncs:services:

the eXtracting Yang Module Python script for IETF +--rw mplsl3vpn* [name]
+--rw name
+--ro modified
string

drafts and RFCs. | +--ro devices*

| +--ro services*
-> /ncs:devices/device/name
instance-identifier

● pyang is Yang validator, transformator and code | +--ro lsa-services*

+--ro directly-modified
| +--ro devices*
instance-identifier

-> /ncs:devices/device/name
generator, written in python, lead by Martin | +--ro services*
+--rw rt
instance-identifier
string

Bjorklund, and constantly improved by the +--rw endpoint* [id]

+--rw id
+--rw rd
string
string
community , especially now that the Yang 1.1 +--rw pe-device
+--rw interfaces
-> /ncs:devices/device/name

specifications [RFC 7950] have published. At the | +--rw ip-address

| +--rw netmask
+--rw (junos)?
inet:ipv4-address
inet:ipv4-address

IETF, pyang is now part of the submission tool | | +--:(junos)

| | +--rw interface -> deref(../../pe-

(thanks to Qin Wu and Dapeng Liu): when posting device)/../ncs:config/junos:configuration/interfaces/interface/name

| | +--rw ip-address-with-mask
| +--rw vlan uint16
junos:ipv4addr

an IETF draft containing a Yang module, the Yang | +--rw bandwidth

+--rw description
string

module language is validated.

21
 Yang tools
• OpenDaylight YANG Tools – Tools supporting NETCONF and
YANG, code generation from YANG models
• https://wiki.opendaylight.org/view/YANG_Tools:Main
• ONOS YANG Tools – Yang Runtime and Java application
support
• https://gerrit.onosproject.org/onos-yang-tools
• YANG Explorer – YANG Browser / RPC Builder
• https://github.com/CiscoDevNet/yang-explorer
• YANG Development Kit (YDK) – APIs bindings generator
• https://github.com/CiscoDevNet/ydk-gen
• https://github.com/CiscoDevNet/ydk-py
• https://github.com/CiscoDevNet/ydk-go
• https://github.com/CiscoDevNet/ydk-cpp

22
 Visual dependency tool – f.e. ietf-ip

Jan Medved developed the

symd.py, which generates a
variety of yang module
dependency graphs and output
suitable for visualization with
D3.js tools. Example shows the
importance of the ietf-ip Yang
module, as it is imported by
many other Yang modules.
23
 Yang Catalog - Yang DB search

The Yang DB search laid

a framework for the
multi-SDO impact
analysis, including a
color scheme for the
standard maturity
levels.
Currently it includes:
● IETF
● BBF
● OpenConfig

24
Agenda

• Orchestration problem statement

• Netconf overview
• Restconf overview
• Yang overview
•OpenDaylight overview
• DEMO

25
What is OpenDaylight?

• Open Source programmable platform hosted by the Linux Foundation

• ~5 Years Old
• Mature, Open Governance
• Mature code base
• ~1000 Individual Contributors from ~140 organizations
• Dozens of OpenDaylight-based solutions
• Many deployments

26
 OpenDaylight: a Yang-based microservices Platform
● Based on Model-
Driven Service OSS/BSS/CMS Controlled
Abstraction Layer (External Apps) YANG- Devices
modeled
(MD-SAL) Interfaces
● Yang
● Data Modeling NB NB
App App
SB SB
Language for API API Protocol Protocol
YANG-
NETCONF modeled
● Creates well- Notifications
Interfaces
defined APIs MD-SAL RPCs Data
● Java and Clustering
RESTCONF APIs
auto-generated
from Yang

27
MD-SAL = Model-Driven Service Abstraction Layer
Applications

NB REST API NB REST API NB REST API NB API NB API

Internal Transformer/ Platform Network
NETCONF RESTCONF
Plugin Adapter Service Plugin Service Plugin

JAVA SAL APIs (Generated)

Network
Topology
NE … NE
NE NE
Tunnels
… Flows System
Links NodesEndPoints
Table
…
Table
Config Stats …
Table Table

Table Config Stats

Paths … … MD-SAL
Flow Flow Flow Flow Flow Flow
JAVA SAL APIs (Generated)

BGP-LS
… PCEP OF x.y OfConfig / OVSDB NETCONF RESTCONF

Network Elements

28
ODL project dependencies

29
Java, Interface, Maven, OSGi, Karaf

● Java chosen as an enterprise-grade,

cross-platform compatible language
● Java Interfaces are used for event listening,
specifications and forming patterns
Feature Feature
● Maven – build system for Java A B …
● OSGi: SAL
− Allows dynamically loading bundles
− Allows registering dependencies and Karaf
services exported
OSGi Framework
− For exchanging information across bundles
(Equinox)
● Karaf: Light-weight Runtime for loading
modules/bundles
− OSGi based. Primary distribution mechanism for Helium

30
 Java, Interface, Maven, OSGi, Karaf

● OpenDaylight has significant support for

REST APIs
● Restconf allows for checking config and
operational state
− feature:install odl-restconf
− http://localhost:8181/restconf/....
● List of exposed Northbound APIs are auto-
generated using swagger.
− feature:install odl-mdsal-apidocs
− http://localhost:8181/apidoc/explorer

31
 NETCONF connector

● To connect the NETCONF/YANG NE to ODL - use network-topology feature:

− feature:install odl-netconf-topology odl-restconf
● Fully capable (full support for Netconf/Yang) device to mount, we need only:
− Name
− Host
− Port
− Username/Password
(for Netconf session)

32
 NETCONF connector (advanced config)
● Advanced configuration
− Schema-cache-directory
− Reconnect-on-changed-schema
− Connection-timeout-millis
− Default-request-timeout-millis
− Max-connection-attempts
− Between-attempts-timeout-millis
− Sleep-factor
− Keepalive-delay
− Yang-module-capabilities
− Yang library
− Concurrent rpc limit

33
 NETCONF connector - what available
● Get datastore
− yang-ext:mount
● Invoke RPC (POST)
− yang-ext:/mount/<module>:<operation>
● Update/Delete a netconf-connector
● Get/Set/Modify mounted NEs configuration
● Get the operational datastore
● Receive notifications from NETCONF NE

34
Agenda

• Orchestration problem statement

• Netconf overview
• Restconf overview
• Yang overview
• OpenDaylight overview
•DEMO

35
vrnetlab – tool for service models CI/CT/CD

● Run your favourite virtual routers in docker for convenient labbing,

development and testing.
● vrnetlab is being developed for the TeraStream project at Deutsche Telekom
as part of an automated CI/CT/CD environment for testing our network
provisioning system.
● It supports: Arista vEOS, Cisco CSR1000v,Cisco Nexus NX-OS, Cisco XRv,
Juniper vMX, Nokia VSR
● Features:
− Use docker and KVM
− Ship as single unit
− Bootstrap
− Flexible networking
− Simple: docker run —privileged -d vr-xrv:5.3.3

36
vrnetlab – tool for service models CI/CT/CD

● vMX runs two VMS:

● control plane
● forwarding plane
● vMX startup scripts is a mess
● vrnetlab makes it simple!

37
vrnetlab – tool for service models CI/CT/CD

38
Join LFN meetup!

Assign to group, we will meet soon!

https://www.meetup.com/Open-Source-Networking-Moscow/

39
 Thank you !
Evgeny Zobnitsev
e-mail: e@zobnitsev.ru
twitter: @ezobn