NETCONF&YANG

What Are NETCONF and YANG

Network Configuration Protocol (NETCONF) is a network device management protocol

that is similar to SNMP. NETCONF provides a framework for users to add, modify, or
delete network device configurations, or query configurations, status, and statistics.

Management
Client YANG model
application
<interfaces> Model definition example:
<interface> list interface {

XML message
<ifIndex>11</ifIndex> key "ifName“;
<ifName>10GE1/0/1.1</ifName> min-elements "0“;
<ifPhyType>10GE</ifPhyType> max-elements “unbounded”;

transmission:
<ifParentIfName>10GE1/0/1 leaf ifName {
</ifParentIfName> config "true“;
<ifNumber>1</ifNumber> type "string“; }
</interface> leaf ifIndex {
</interfaces> config "false“;
</ifm> type "uint32“;
}
}

YANG model YANG model YANG model

Server

Datastores Datastores Datastores

Similar to SNMP that uses MIB files to model data, NETCONF uses Yet Another Next
Generation (YANG) as a data modeling language to describe the interaction models
between the NETCONF client and server.

Comparison Item SNMP NETCONF CLI

Defined by IETF IETF None

Resource form OID XPATH None

Data model file .mib .yang No model

Modeling language SMI YANG None

Operation manag-
ement protocol SNMP NETCONF None

Coding mode BER XML Pure text

Transmission UDP SSH TELNET/SSH

protocol

Why Are NETCONF and YANG Required

The traditional CLI mode is based on man-machine interfaces. The configuration is

complex and varies with vendors. Therefore, the manual learning cost is high.

The traditional CLI mode is based on man-machine interfaces. The configuration is

complex and varies with vendors. Therefore, the manual learning cost is high.

The same command

is implemented in Lack of version
different ways on management
different devices
Lack of data Difficult to
models maintain

CLI
The devices of
Security
different vendors fail
Difficult to risk
to communicate with communicate Telnet connection
each other

Complex in
parsing

Syntax and semantic parsing is

complex, which is not conducive
to network programming

The SNMP configuration efficiency is low, and the transaction mechanism is not
supported. Therefore, SNMP is often used for monitoring.

Poor reliability Digital index (1.3.6.1.2.1.2.2.1.4)

Insufficient Data configuration and reading are low, especially in

performance the deployment of large-scale networks

Difficult to deliver
configurations Few MIB objects that support the write operation

No support for the SNMP operations are stateless. Therefore, the operations
transaction
mechanism cannot be interrupted in the case of a configuration failure

No support for Configuration rollback cannot be performed in the case of a

configuration rollback configuration failure
Poor Lack of composite data structures, few RPC interfaces, and
programmability
time-consuming commissioning

NETCONF uses a hierarchical protocol framework, better

1 meeting the on-demand, automatic, and big data
requirements of cloud-basednetworks.
Separation of configuration,
status, and statistics
Configuration, status, and statistics
can be queried separately.
The collection of a large amount of
data is 10 times faster than that of
SNMP.

Support for the transaction

mechanism and rollback
operation
Two-phase configuration is
supported.
Content layer Rollback is supported for error
defines content data recovery.

Good scalability
Vendors can customize new
Operations layer capabilities to implement specific
On-demand
defines the RPC method functions.
Data types/structures can be
extended.
Automation

Messages layer XML-based coding

provides the RPC Flexible and complex hierarchical
mechanism for request Big data
and reply messages
data in text files, model-driven,
and high storage efficiency.
Reuse of the traditional XML tool.

Secure transport layer

establishes connections RPC-based operations
and sures data
transmission security The RPC method is used to
implement operations and control.
Abundant operation interfaces are
defined.

Connection-oriented
The connection-oriented transport
layer protocol SSH/SSL is used,
improving security and reliability.

NETCONF supports classified data storage and migration,

2 phase-based committing, and configuration isolation.
<running/>: <running/> configuration datastore that stores the complete set
of active configurations of a network device.
<candidate/>: <candidate/> configuration datastore that stores various
configuration data to be committed to the <running/> configuration
datastore. Changes in the <candidate/> configuration datastore do
not directly affect the involved device.
<startup/>: <startup/> configuration datastore that stores configuration data
loaded (similar to a saved configuration file) during device startup.

Data can be migrated between configuration datastores：

Running <copy-config> Startup

R unning
Candidate <commit> Running

Candidate <commit> Running <copy-config> Startup

NETCONF defines abundant operation interfaces and

3 supports extension based on capability sets.

Basic Operations Supported by NETCONF (RFC 6241)

<get>: obtains part or all of the running configuration data and status data from
the <running/> configuration datastore.
<get-config>: obtains configuration data.
<edit-config>: creates, modifies, or deletes configuration data.
<copy-config>: replaces a configuration datastore with the contents of another
complete configuration datastore.
<delete-config>: deletes all data in a non-running configuration datastore.
<lock>: locks the configuration datastore of a device. A locked configuration
datastore cannot be modified by other NETCONF users.
<unlock>: unlocks the configuration datastore of a device.
<close-session>: terminates a NETCONF session gracefully.
<kill-session>: forcibly terminates another NETCONF session.

Capabilities That Can Be Extended

RFC 6241: RFC 5277：

Writable-Running Notification
Candidate Configuration Interleave
Confirmed Commit
Rollback-on-Error Validate RFC 6243：
Startup with-defaults
URL
XPath RFC 6022：
IIetf-netconf-monitoring

4 NETCONF operations are performed based on the YANG model.

The YANG model defines device function configu-
ration templates. Compared with the CLI mode,
the YANG model has the following advantages:
Rich definition: Various basic data types and data attributes can be defined.
Machine language: Structured definition is adopted, allowing users to define
constraints that can be directly identified by the computer without manual
intervention.
Good scalability: The grouping, refine, augment, and typedef statements are
supported for users to extend YANG models and data types.
Easy integration: The IETF defines multiple YANG models and data types for
reference.

Command line example: Information to be manually entered:

ip address ip-address { mask | mask-length } ip address 1.1.1.1 24

YANG model example: XML request packet sent by the client:

{ list ip <ip xmlns="http://www.huawei.com/

when "not(../../addrCfgType='negotiation')"; netconf/vrp/huawei-ip">
key ip-address <ip-address>1.1.1.1</ip-address>
{ leaf ip-address <mask>24</mask>
type inet:ipv4-address-no-zone </ip>
leaf mask
type ifmIpv4Mask}
}

If functions are implemented in different

ways on devices from different vendors:
In traditional CLI mode, engineers need to learn the differences between command
lines of different vendors and manually map the command lines.

Service User

Step1 Read relevant documentation Function Engineer

Step2 Learn relevant differences.
Is there any function implementation
difference?
Is there any difference between
command line formats?
Is there any configuration
constraint and dependency?
Step3 Manually enter the desired
command

Device running data Device running data

IPv4-specific command format: IPv4 and IPv6 use the same
ipv4 address ipv4-address { command format. ip address
mask | mask-length } IPv6-spe- ip-address { mask |
cific command format: ipv6 mask-length }
address { ipv6-address
prefix-length | ipv6address/pre-
fix-length }
Device
Device of vendor A Device of vendor B

If functions are implemented based on YANG models, configuration engineers do not need to
pay attention to the definitions of YANG models and the differences between the YANG
models. The corresponding application automatically parses the YANG model data, shifting the
focus of engineers from device and function differences to user requirements. The engineers
can achieve automatic configuration only by operating the graphical application.

User Service

Engineer Function

Client APP
Adaptation layer

YANG model A YANG model B

Automatic XML Automatic XML
packet generation packet generation
Device running data Device running data
YANG model A: YANG model B:
{ ip { ip
{ ipv4 { ip-address
{ ipv4-address mask }
mask } }
}
{ ipv6
{ ipv6-address
mask }
}
}

Server
Device of vendor A Device of vendor B

NETCONF and YANG Development

RFC 3535 RFC 6020

NETMOD released the basic A large number of YANG-based
The Internet Architecture Board drafts were released.
(IAB) considered that a series of definition of the YANG language
network management problems and the method of combining
existed and needed to be resolved NETCONF and YANG.
using new methods.

2015-
2002.6 2006.11 2010.10 2011.7 2014
2016

YANG became a
RFC 4771 RFC 6241 mainstream data model
The NETCONF workgroup released the first The NETCONF workgroup released the in the industry.
version of NETCONF, defining the basic second version of NETCONF and
NETCONF framework and operations. This determined the combination with YANG.
version did not clearly define the content layer
but solved some problems raised in RFC 3535.

YANG drives the development of NETCONF.

Universal models are defined based on YANG, making a breakthrough in NETCONF
implementation and laying the foundation for model unification between vendors.
YANG-based network models are implemented on devices of different vendors,
promoting NETCONF development.

Example for the Basic NETCONF Session Process

Scenario: Use a NETCONF client to change the IP address of a device in two-phase

validation mode.

Prerequisites: The SSH connection, authentication, and authorization are complete.

Client Server

Step 1 Establish a NETCONF session and advertise capabilities through<hello> messages.

Hello. I support the following capabilities: Hello. I support the following capabilities:

<hello xmlns="urn:ietf:params:xml:ns: <hello xmlns="urn:ietf:params:xml:ns:

netconf:base:1.0"> netconf:base:1.0">
<capabilities> <capabilities>
<capability>urn:ietf:params:netconf: <capability>urn:ietf:params:netconf:
base:1.1</capability> base:1.1</capability>
</capabilities> </capabilities>
</hello> <session-id>1</session-id>
</hello>

Step 2 Lock the <running/> configuration datastore to avoid conflicts with other clients.

I request to lock the <running/> configura-

tion datastore so that my operations will OK.
not be affected.

<rpc xmlns="urn:ietf:params:xml:ns: <rpc-reply message-id=“2“ xmlns="

netconf:base:1.0" message-id="2"> urn:ietf:params:xml:ns:netconf:
<lock> base:1.0">
<target> <ok/>
<running></running> </rpc-reply>
</target>
</lock>
</rpc>

Copy the data in the <running/> configuration datastore to the <candidate/>

Step 3
configuration datastore to ensure that the configurations are the latest.

I request to copy data. OK.

<rpc xmlns="urn:ietf:params:xml:ns: <rpc-reply message-id="3" xmlns=

netconf:base:1.0" message-id="3"> "urn:ietf:params:xml:ns:netconf:
<copy-config> base:1.0">
<target> <ok/>
<candidate></candidate> </rpc-reply>
</target>
<source>
<running></running>
</source>
</copy-config>
</rpc>

Step 4 Edit configurations in the <candidate/> configuration datastore.

I request to configure 1.1.1.1 as the IP

address of GE 1/0/0. OK.

<interfaces> list interface {

<interface> key "ifName“;
<ifIndex>11</ifIndex> min-elements "0“;
<ifName>10GE1/0/1.1</ifName> max-elements “unbounded”;
<ifPhyType>10GE</ifPhyType> leaf ifName {
<ifParentIfName>10GE1/0/1 config "true“;
</ifParentIfName> type "string“; }
<ifNumber>1</ifNumber> leaf ifIndex {
</interface> config "false“;
</interfaces> type "uint32“;
</ifm> }
}

Step 5 Commit configurations in the <candidate/> configuration datastore to the <run-

ning/> configuration datastore.

OK. The configurations have been

I request to commit configurations. committed to the <running/> configuration
datastore.
<rpc xmlns="urn:ietf:params:xml:ns: <rpc-reply message-id=“6“ xmlns=
netconf:base:1.0" message-id="6"> "urn:ietf:params:xml:ns:netconf:base:1.0">
<commit></commit> <ok/>
</rpc> </rpc-reply>

Step 6 Unlock the <running/> configuration datastore.

The configuration is complete, and the

<running/> configuration datastore can be OK.
unlocked.
<rpc xmlns="urn:ietf:params:xml:ns: <rpc-reply message-id=“7" xmlns="urn:ietf:
netconf:base:1.0" message-id="7"> params:xml:ns:netconf:base:1.0">
<unlock> <ok/>
<target> </rpc-reply>
<running></running>
</target>
</unlock>
</rpc>

Follow-up procedure Terminate the NETCONF session and tear down the SSH connection.

Acronyms and Abbreviations

Abbreviations English

NETCONF Network Configuration Protocol

XML Extensible Markup Language

RPC Remote Procedure Call

YANG Yet Another Next Generation