This document provides an overview of a workshop held by the IAB on network management. The goal of the workshop was to continue discussions between network operators and protocol developers and guide the IETF's focus on future work regarding network management.

2. OpenDaylight YANG
model Overview
Giles Heron – Principal Engineer

3. Why NETCONF/YANG - Informational RFC 3535
• SNMP had failed
• For configuration, that is
• Extensive use in fault handling and
monitoring
• CLI scripting
• “Market share” 70%+
Abstract
This document provides an overview of a
workshop held by the Internet Architecture Board
(IAB) on Network Management. The workshop
was hosted by CNRI in Reston, VA, USA from
June 4 thru June 6, 2002. The goal of the
workshop was to continue the important dialog
started between network operators and
protocol developers, and to guide the IETFs
focus on future work regarding network
management.
configuration

4. NETCONF and YANG in Context
NETCONF
Manager
NETCONF
Yang
Models
YANG ModelsYANG Models
YANG Models
YANG Models
Management
Applications

5. What is a Data-Model? What is a Network
Management Protocol?
• Data-Model
• A data-model explicitly and precisely determines the
structure, syntax and semantics of the data…
• …that is externally visible
• Consistent and complete
• Protocol
• Remote primitives to view and manipulate the data
• Encoding of the data as defined by the data-model
Data-Model
Protocol

6. Confusion and Comparison
• Data-Models and information Models
• Information models are for humans
• Not everything
• Not always detailed and precise
• Starting-point for data-model
• Protocol
• Confusion between domain-specific network management
protocols and general RPC mechanisms
• NETCONF vs. CORBA, SOAP, REST, …
Data-Model
MIB Modules
YANG Modules
Protocol
The SNMP Protocol
NETCONF

7. What is YANG?
• YANG – Yet Another Next-Generation...
• ... Communication Protocol?
• ... Messaging Bus?
• ... Management Information Definition Language!
• Purpose
• Define management information for Netconf...
• ... Original focus on configuration information, but not restricted to it
• ... Can be separated from Netconf
(not a goal of the specification, but an important aspect)

8. YANG and XML
• YANG assumes an XML encoding of instantiated information
• Defines XML rendering rules
• Relies on XML encoding for certain advanced features (e.g. expression of constraints
using Xpath)
• Facilitates describing XML document hierarchies
• Nicely aligned with NETCONF 
• YANG itself is not XML
• Emphasis on readability
• Familiar structure to C/C++ or Java programmers
• XML notation exists: YIN (Yang-Independent Notation)
• Semantic equivalence
• Syntactic conversions YANG <-> YIN
• Alternative encodings defined (e.g. JSON for RESTconf)

9. YANG compared to SNMP
Definition language:
YANG
Information model:
YANG modules
Instantiated data:
XML
Transport:
Netconf
Definition language:
SMIv2
Information model:
MIB modules
Instantiated data:
ASN.1 BER
Transport:
SNMP
“Content”
“Payload”
“Framework”
Compare SNMP
Import conversion rules exist
(MIBs  YANG)
“instant content”
Ability to express hierarchy
(compare MIBs: flat + tables)
Richer conditions, constraints
Facilities for easier reuse
RPC/Action support
Human readability
Dynamic extensibility
B2B, Web toolkits
Bulk vs only incremental ops
(manipulation of config files,
e.g. edit-config)
Transaction support
Configuration vs monitoringor possibly other
(no inherent dependency but
will require different bindings)

10. YANG in the context of Netconf
Transport
Remote
Operations
Mgmt
Services
Mgmt info
(payload)
Mgmt info
(definition)
XML-encoded content
YANG modules
Netconf operations
<edit-config>, <get-config>, <get>
Netconf RPC
<rpc>, <rpc-reply>
TLS, SSH
Manager
(client)
XML
content
per
YANG
Conceptual
Data
Store
Agent
(server)

11. YANG
• Data modeling language
• Configuration data
• State data
• Tree structure
• Data and Types
acme-box module
properties container
interfaces container
name: string, config
name: string, config
interface: list, key = name
oper-state: enum, config

12. RESTCONF
• ReSTful protocol to access YANG defined data
• Remote State Transfer, i.e. server maintains no session state
• HTTL URLs reflect data hierarchy in a YANG-modelled datastore
RESTCONF Netconf
GET <get-config>, <get>
POST <edit-config> (“create”)
PUT <edit-config> (“replace”)
PATCH <edit-config> (“merge”)
DELETE <edit-config> (“delete”)
OPTIONS (discover supported operations)
HEAD (get without body)

13. Resource URI Map
/restconf
/config
/<top-level-data-nodes> (configuration data)
/operational
/<top-level-data-nodes> (operational data)
/modules
/module
/name
/revision
/namespace
/feature
/deviation
/operations
/<custom protocol operations>
/streams
/stream
/name
/description
/replay-support
/replay-log-creation-time
/events
/version (field)
Event streams,
subscribe using “get”,
can specify filters
Meta-information:
Capabilities etc
Meta-information:
Supported RPCs
YANG-
defined
data

14. ODL
Transport
Remote
Operations
Mgmt
Services
Mgmt info
(encoding)
Mgmt info
(definition)
XML-encoded
content
YANG modules
NETCONF
operations
XML
RPC
TLS,
SSH
JSON
JAVA
DTO
I2RS
?
HTTP
RESTCONF
TCP
YANG - NETCONF, RESTCONF, I2RS & IDL

15. Controller
YANG IDL – OpenDaylight MD-SAL
MD-SAL
DOM BrokerBA-BI Connector
Mapping Service
Codec Registry
Schema Service
Codec Generator
Binding-Aware
Broker Data Store
Binding-Aware to Binding-Independent Data Translation
Binding-Aware Plugin
Binding-Independent
Plugin/Client
(NETCONF/RESTCONF)
Forwarding Rules Manager,
Stats Manager, BGP-LS/PCEP
RESTCONF Clients
Internal Clients
YANG
Models

16. Mounting Remote Datastores
OpenDaylight Controller Config
MD-SAL
NETCONF
NETCONF
• Mounted under e.g. http://localhost:8181/restconf/config/opendaylight-
inventory:nodes/node/controller-config
• Data can be accessed using …/yang-ext:mount/…
• …/yang-ext:mount/config:modules is used to configure the various plug-ins
Config Store
RESTCONF

17. Mounting Remote Datastores
OpenDaylight NETCONF Node “Discovery”
MD-SAL
NETCONF
RESTCONF
Node Inventory
• Nodes added by POSTing to config:modules
• ODL connects to each node
• ODL learns capabilities (YANG modules) and stores to model cache
• Cache at ~/cache/schema. Filenames of form yang-model@2015-06-07.yang.
Model Cache
XR1 XR2 OpenWRT

18. Mounting Remote Datastores
OpenDaylight NETCONF Node Configuration
MD-SAL
NETCONF
RESTCONF
Node Inventory
• Nodes configured by POSTing or PUTting to e.g.:
• http://localhost:8181/restconf/config/opendaylight-inventory:nodes/node/XR2/yang-
ext:mount/Cisco-IOS-XR-ifmgr-cfg:interface-configurations/interface-
configuration/act/Loopback0/
• Can retrieve config (or operational stats) using GET
Model Cache
XR1 XR2 OpenWRT

19. Thank you