NETCONF & YANG Enablement of Network Devices

NETCONF & YANG Enablement of Network Devices

John Lawitzke – ConfD Product ManagerDEVNET-1216

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 2DEVNET-1216

• Introduction• Why NETCONF and YANG?• NETCONF Overview• YANG Overview• ConfD for Implementing NETCONF and YANG• Demo• Q & A

Agenda


Why NETCONF and YANG?


Origins of NETCONF and YANG• June, 2002 – IETF Internet Architecture Board holds a Network Management

Workshop to assess the state of network management and develop requirements for next generation

• Workshop results were published as informational RFC 3535

• The workshop identified the need for a NETwork CONFiguration protocol• SNMP good for monitoring; not being used for configuration• CLI scripting is problematic, complex, time consuming, and costly

• The IETF NETCONF working group was born• Later, the IETF NETMOD working group was formed to work on YANG

• Although not envisioned at the time, the end result has been a programmable device interface ideally suited for use in SDN and NFV


RFC 3535 Key Operator Requirements • Ease of use for the operator

• Separate configuration data from operational state data and statistics

• Focus on management of services and networks and not individual devices

• Network wide transactions

• Text based configuration is important in order to leverage existing text based processing tools

• Standardized data models

• Role Based Access Control which is both data and task oriented

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public

NETCONF Overview

6DEVNET-1216

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 7

NETCONF Transport• NETCONF is connection oriented using TCP

• NETCONF messages are:• Encoded in XML• Encrypted by SSH

• NETCONF is extensible• When a NETCONF client (manager) connects to a NETCONF server (agent), they

exchange <hello> messages• <hello> messages declare what capabilities and YANG data models are supported

• NETCONF defines startup, running, and candidate data stores

• NETCONF is transactional and can be used to easily implement network-wide transactions

DEVNET-1216


NETCONF TransactionsNETCONF allows a Manager to send a set of configuration changes in a single <edit-config> transaction.

When doing so, the Manager does not need to:• Figure out which order to send down the configuration changes in. All different sequences

are treated equal.

• Recover if the transaction fails. If the transaction was unsuccessful because of• inconsistency in the configuration• an out of memory condition• any other reason

… none of the transaction content has been activated.

The transaction did not roll back. It was simply never activated.

DEVNET-1216


NETCONF Network-wide TransactionsA NETCONF Manager can use the Candidate data store to implement a network wide transaction:• Send a configuration change to the Candidate data store of each participating device

• Validate Candidate

• If all participants are fine, tell all participating devices to commit or confirmed-commit the changes

DEVNET-1216


NETCONF Base Operations• <get>

• <get-config>

• <edit-config>• test-option (:validate)• error-option • operation

• <copy-config>

• <commit> (:candidate, :confirmed)

• <discard-changes> (:candidate)

• <cancel-commit> (:candidate)

• <delete-config>

• <lock>

• <unlock>

• <close-session>

• <kill-session>

DEVNET-1216


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> </config> </edit-config></rpc>

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

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

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

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

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

DEVNET-1216


NETCONF Optional CapabilitiesRFC 6241 Optional Capabilities:

:writable-running

:candidate

:confirmed-commit

:rollback-on-error

:validate

:startup

:url (scheme=http, ftp, file, …)

:xpath (filters)

Non-base NETCONF Capabilities:

:notification, :interleave (RFC 5277)

:partial-lock (RFC 5717)

:with-defaults (RFC 6243)

:ietf-netconf-monitoring (RFC 6022)

DEVNET-1216


YANG Overview

13DEVNET-1216


What is YANG?• YANG is an easily readable data modeling language defined in RFC 6020

• YANG models both the syntax and the semantics of the data

• YANG maps 1:1 to XML• A YANG module is a XML namespace

• The basic YANG statements for organizing data are “container”, “list”, and “leaf”

• YANG provides a rich set of base data types (20+) from which other data types can be derived using “typedef”

• Reusable groups of data can be defined using “grouping”

• Relationships are modeled using “leafref”

• Constraints are modeled using “must”, “unique”, etc.


YANG Example typedef ipv4-address { type string { pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; } } container interfaces { list interface { key "name"; unique "ip_addr"; leaf name { type string; } leaf ip_addr { type ipv4-address; } leaf metric { type uint32 { range "1..100"; } } must "sum(../interface/metric) <= 100"; } }

DEVNET-1216


Validation Constraints typedef ipv4-address { type string { pattern '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}' + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'; } } container interfaces { list interface { key "name"; unique "ip_addr"; leaf name { type string; } leaf ip_addr { type ipv4-address; } leaf metric { type uint32 { range "1..100"; } } must "sum(../interface/metric) <= 100"; } }

DEVNET-1216


ConfD for ImplementingNETCONF and YANG

17DEVNET-1216


What is ConfD?• ConfD is a data model driven framework which provides a full set of

transactional management plane services and includes a variety of standards based northbound interfaces for use in building network elements:• Physical Network Devices• Virtual Network Devices

• (e.g. VNF in NFV)• Network Appliances• etc.

DEVNET-1216


What does Data Model Driven Mean?• Data models are written in the YANG data modeling language (RFC 6020)

• ConfD uses the data model to drive and automate processing:• Auto-renders northbound interfaces• Automatically controls CDB database schema• Automatically performs syntactic and semantic data validation• Determines API interaction

• Data items are identified based on path in the data model organization• + more• Reduces your code development

• Model once; write once; use many.• Instrumentation code is written in terms of the data model not the northbound interface• A YANG model and its common set of instrumentation can be used across all APIs and northbound

interfaces

DEVNET-1216


ConfD Architecture

CDB API

ConfDNETCONF REST SNMP CLI

ConfD Core Engine

CDBDatabase

Transaction Management

Session Management / AuthenticationRole-based Access Control / Authorization

Audit Trailing

Redundancy / Replication

Validation (syntactic and semantic)Rollback Management

Upgrades and Downgrades

Data Provider API

Management Agent API

App

External Databas

e

Operational

DataProvider

(pull mode)App

Valid

atio

nAP

I

Auth

entic

atio

n APIExternal

Authenticator

Action Handler

Validation Handler

Configuration Reader

and Subscriber

Operational

DataProvider

(push mode)

YANGData

Models

DEVNET-1216

Web API


Demo


Q&A

22DEVNET-1216


Complete Your Online Session Evaluation

Don’t forget: Cisco Live sessions will be available for viewing on-demand after the event at CiscoLive.com/Online

• Give us your feedback to be entered into a Daily Survey Drawing. A daily winner will receive a $750 Amazon gift card.

• Complete your session surveys through the Cisco Live mobile app or from the Session Catalog on CiscoLive.com/us.

23DEVNET-1216

http://ciscolive.com/Online

http://ciscolive.com/us

© 2016 Cisco and/or its affiliates. All rights reserved. Cisco Public 24Presentation ID

Continue Your Education• Demos in the Cisco campus

• Walk-in Self-Paced Labs

• Lunch & Learn

• Meet the Engineer 1:1 meetings

• Related sessions


Please join us for the Service Provider Innovation Talk featuring:

Yvette Kanouff | Senior Vice President and General Manager, SP BusinessJoe Cozzolino | Senior Vice President, Cisco Services

Thursday, July 14th, 201611:30 am - 12:30 pm, In the Oceanside A room

What to expect from this innovation talk• Insights on market trends and forecasts• Preview of key technologies and capabilities • Innovative demonstrations of the latest and greatest products• Better understanding of how Cisco can help you succeed

Register to attend the session live now or watch the broadcast on cisco.com

Presentation ID 25


Continue Your Education• For more information about ConfD:

• https://developer.cisco.com/site/confD/• Links to download ConfD Basic, training videos, user forum, and more• Videos include NETCONF and YANG tutorials

• http://www.tail-f.com • For more info, contact: [email protected]

https://developer.cisco.com/site/confD/

https://developer.cisco.com/site/confD/

http://www.tail-f.com/

mailto:[email protected]

Thank you


Technology

NETCONF & YANG Enablement of Network Devices