1.
A 30-minute Introduction to NETCONF and YANGCarl Moberg <calle@tail-f.com>twitter: @cmobergLast 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! 2

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 3

4.
NETCONF and YANG Brief TimelineNETCONF YANG• 2001 • 2007 IETF Meeting with poll of YANG design team proposal SNMP SET usage • Apr 2008• June 2002 NETMOD WG established IAB Network Mgmt Workshop • Oct 2010• May 2003 YANG RFC 6020 published NETCONF WG established• Dec 2006 NETCONF core RFCs published 4

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 5

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 6

7.
NETCONF Layering Model Layer NETCONF Content Configuration Data Operations <get> <get-config> <notification> <rpc> RPC <rpc-reply> Transport SSH, SSL, BEEP, etc Protocol 7

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 8

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 9

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 10

11.
YANG Examplemodule 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”; } 11

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; } } }} 12

13.
Known NETCONF Vendor Implementations – Alaxala – Juniper Networks • Ethernet switches • JUNOS 7.5 and later – BATM/Telco Systems – Nexor • T-Metro 7224 • Messaging Gateways – BigBand – RuggedCom • MSP2800 • RX5000 and MX5000 – Brocade – Sonus • NetIron XMR, CES, and CER • NBS5200 Session Border Controller • MLX Series – Taseon • VDX (Announced, not released) • TN 320 – Cisco – Verivue • IOS 12.4(9)T and later • MDX 9020 • IOS XE 2.1 and later – Edgeware • WTV-2X – Ericsson • SEA 20 Entries in italics is new in this version of the – H3C presentation • S9500E Series Routing Switches Please Note that this list is work in – Huawei • AR3200/2200 Enterprise Routers progress and feedback on accuracy and completeness is strongly encouraged 13

14.
Available NETCONF ImplementationsCommercial Products Open Source Projects – Applied Informatics • POCO NETCONF (server) – Ncclient (client) – Centered Logic – NetconfX (client) • NetconfX (client) – Netconf4Android – Oracle/GoAhead • NETCONF MindAgent (server) (client) – SNMP Research – netconf4j (client) • EPIC NETCONF (server) – netopeer (client/server) – Tail-f Systems • ConfD (server) – YencaP (client/server) • NCS (client) – Yuma (client/server) – Velankani • NOCVue ConfigMan Please Note that this list is work in – WebNMS progress and feedback on accuracy and • WebNMS Framework (client) completeness is strongly encouraged 14

15.
Available YANG Implementations• Commercial Products • Open Source Projects – MG Soft Corporation – jYang – Oracle/GoAhead – libsmi – SNMP Research – Pyang – Tail-f Systems – yang-mode for Emacs – Yuma Please Note that this list is work in progress and feedback on accuracy and completeness is strongly encouraged 15

16.
Standards Organizations Activities• IETF – YANG models for Service – NETCONF working group OAM PM and FM focusing on: – To be published • Access Control • System Notifications – NETMOD (YANG) working group currently focusing on: – YANG module for CCAP: next • Interfaces, routing and system generation cable head-end systems data modules – Part of the Converged Cable • SMIv2-to-YANG translation Access Platform Support – Always updated: System Interface Specification • http://tools.ietf.org/wg/netconf/ • http://tools.ietf.org/wg/netconf/ Please Note that this list is work in progress and feedback on accuracy and completeness is strongly encouraged 16

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 17

18.
18

19.
Backup Slides 19

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) 20

21.
A Layered Comparison SNMP NETCONF SOAPData models MIBs ModulesData Modeling SMI YANGLanguageManagement SNMP NETCONFOperationsRPC Protocol BER XML XMLTransport Stack UDP SSH SSL BEEP HTTP SOAP TCP TLS 21