3. Some Background
01
02
NETCONF is an IETF configuration management
protocol and YANG is its data modeling language
SNMP
– Lack of support
– No concept of transactions
4. NETCONF and YANG Brief Timeline
IETF Meeting with poll of
SNMP SET usage
2001
IAB Network Mgmt Workshop
June 2012
NETCONF WG established
May 2003
YANG design team proposal
2007
NETMOD WG established
April 2008
YANG RFC 6020 published
Oct 2010
01
02
03
01
02
03
NETCONF YANG
NETCONF core RFCs
published
Dec 2006
04
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
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
8. Basic NETCONF Operations
1. Get configuration <get-config>
Retrieve all or part of a specified configuration from a named data store
2. Get all information <get>
Retrieve running configuration and device state information
3. Edit configuration <edit-config>
Loads all or part of a specified configuration to the specified target
configuration
4. Copy configuration <copy-config>
Create or replace an entire configuration datastore with the contents of
another complete configuration datastore.
9. Basic NETCONF Operations
6. Delete configuration <delete-config>
Delete a configuration datastore (not applicable to running)
7. Lock and unlock <lock>, <unlock>
Short-lived lock and unlock of the configuration system of a device
8. Close and kill session <close-session>, <kill-session>
Graceful (close) or forced (kill) termination of a NETCONF session
10. YANG Feature Highlights
Leaf, leaf-list, container, lists, grouping, choice
Organization
Module, submodule, augment, if-feature, when
Data model structure
Must, unique, min-elements, max-elements,
mandatory
Constraints
01
02
03
Many built-in types, sub-typing, restrictions
Data types
04
Grouping, uses
Reusable groupings
05
13. Known NETCONF Vendor Implementations
Brocade
• NetIron XMR, CES, and CER
• MLX Series
• VDX (Announced, not released)
Cisco
• IOS 12.4(9)T and later
• IOS XE 2.1 and later
Juniper Networks
• JUNOS 7.5 and later
Huawei
• AR3200/2200 Enterprise Routers
14. Available NETCONF Implementations
– Applied Informatics
POCO NETCONF (server)
– Centered Logic
NetconfX (client)
– Oracle/GoAhead
NETCONF MindAgent (server)
– SNMP Research
EPIC NETCONF (server)
– Tail-f Systems
ConfD (server)
NCS (client)
Open Source Projects Open Source Projects
– Ncclient (client)
– NetconfX (client)
– Netconf4Android (client)
– netconf4j (client)
– netopeer (client/server)
– YencaP (client/server)
15. Overview
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
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
