Yang in OpenDaylight

Yang Modeling in OpenDaylight

Jan Medved

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

Agenda

•  Yang Overview

•  Netconf/Yang in OpenDaylight

•  Example/Demo

•  Pointers

Yang Overview


YANG is ….

•  A NETCONF modeling language –  Think SMI for NETCONF

•  Models semantics and data organization –  Syntax falls out of semantics

•  Able to model config data, state data, RPCs, and notifications

•  Based on SMIng syntax –  Text-based

•  Email, patch, and RFC friendly


YANG Concepts

leafs

config data

types

RPCs notifications

Standard Models

Proprietary Models

containers


YANG ....

•  Directly maps to XML content (on the wire)

•  Extensible –  Add new content to existing data models

•  Without changing the original model –  Add new statements to the YANG language

•  Vendor extensions and future proofing

•  Preserves investment in SNMP MIBs –  libsmi translates MIBs to YANG

•  See tools at www.yang-central.org


Semantics and syntax

YANG

Relax-NG XML Schema Anything Else

Legacy tools Out

going XML

Semantic World

Syntactic World

Validation


YANG values .... •  Readers and reviewers time and learning curve

–  Readability is highest priority •  Limited Scope

–  Doesn't boil the ocean –  Maximize utility within that scope –  Can be extended in the future

•  Experience gained by existing implementations –  Based on four proprietary modeling languages

•  Years of experience within multiple vendors

•  Quality draft backed by running code


Modules and submodules

•  Header statements –  yang-version, namespace, prefix

•  Linkage statement –  import and include

•  Meta information –  organization, contact

•  Revision history –  revision

SubX SubY SubZ

SubA

Mod1

Mod2

Include

Import

Include


module acme-module {! namespace "http://acme.example.com/module";! prefix acme;!! import "yang-types" {! prefix yang;! }! include "acme-system";!! organization "ACME Inc.";! contact [email protected];! description "The module for entities ! implementing the ACME products";!! revision 2007-06-09 {! description "Initial revision.";! }! …!}!


The "leaf" Statement

YANG Example:!!leaf host-name {! type string;! mandatory true;! config true;! description "Hostname for this system";!}!

• A leaf has – one value – no children – one instance

NETCONF XML Encoding:!!<host-name>my.example.com</host-name>!


The "leaf-list" Statement

YANG Example:!!leaf-list domain-search {! type string;! ordered-by user;! description "List of domain names to search";!}!

•  A leaf-list has: –  one value –  no children –  multiple instances

NETCONF XML Encoding:!!<domain-search>high.example.com</domain-search>!<domain-search>low.example.com</domain-search>!<domain-search>everywhere.example.com</domain-search>!


YANG Example:!!container system {! container services {! container ssh {! presence "Enables SSH";! description "SSH service specific configuration";! // more leafs, containers and stuff here...! }! }!}!

The "container" Statement n  A container has"

n  no value"n  holds related children"n  one instance"

NETCONF XML Encoding:!!

<system>! <services>! <ssh/>! </services>!</system>!

May have specific meaning (presence)

Or may simply contain other nodes


The "must" Statement container timeout {! leaf access-timeout {! description "Maximum time without server response";! units seconds;! mandatory true;! type uint32;! }! leaf retry-timer {! description "Period to retry operation";! units seconds;! type uint32;! must "$this < ../access-timeout" {! error-app-tag retry-timer-invalid;! error-message "The retry timer must be "! + "less than the access timeout";! }! }!}!

•  Constrains nodes by Xpath expression


The "list" Statement YANG Example:!!list user {! key name;! leaf name {! type string;! }! leaf uid {! type uint32;! }! leaf full-name {! type string;! }! leaf class {! type string;! default viewer;! }!}!

NETCONF XML Encoding:!!��<user>! <name>glocks</name>! <full-name>Goldie</full-name>! <class>intruder</class>!</user>!<user>! <name>snowey</name>! <full-name>Snow</full-name>! <class>free-loader</class>!</user>!<user>! <name>rzull</name>! <full-name>Repun</full-name>!</user>!

•  A list is –  uniquely identified by key(s) –  holds related children –  no value –  multiple instances


The "augment" Statement

YANG Example:!!augment system/login/user {! leaf expire {! type yang:date-and-time;! }!}!

NETCONF XML Encoding:!!<user>! <name>alicew</name>! <class>drop-out</class>! <other:expire>2112-04-01T12:00:00</other:expire>!</user>!!

•  Extends data model –  Current or imported modules

•  Inserts nodes –  Into an existing hierarchy –  Nodes appear in current module's

namespace –  Original (augmented) module is

unchanged


The "when" Statement

YANG Example:!!augment system/login/user {! when "class = wheel";! leaf shell {! type string;! }!}!

NETCONF XML Encoding:!!<user>! <name>alicew</name>! <class>wheel</class>! <other:shell>/bin/tcsh</other:shell>!</user>!

•  Makes sparse augmentation –  Nodes are only added when

condition is true –  "when" is XPath expression


Built-in ^ypes

Category! Types!Integral" {,u}int{8,16,32,64}"String" string, enumeration, boolean"Binary Data" binary"Bit fields" bits"References" instance-identifier, keyref"Other" empty"


YANG Example:!!typedef percent {! type uint16 {! range "0 .. 100";! }! description "Percentage";!}!!leaf completed {! type percent;!}!

Derived Types

NETCONF XML Encoding:!!<completed>20</completed>!

•  Constraints –  range –  length –  pattern

•  regex

•  A modules may use types imported from other modules


YANG Example:!!leaf limit {! description "Number to allow";! type union {! type uint16 {! range "0 .. 100";! }! type enumeration {! enum none {! description "No limit";! }! }! }!}!

The "union" type

•  Allows a leaf to contain a superset of types

NETCONF XML Encoding:!!<limit>20</limit>!

NETCONF XML Encoding:!!<limit>none</limit>!


The "grouping" Statement YANG Example!!grouping target {! leaf address {! type inet:ip-address;! description "Target IP address";! }! leaf port {! type inet:ip-port;! description "Target port number";! }!}!container peer {! container destination {! uses target;! }!}!

NETCONF XML Encoding:!!<peer>! <destination>! <address>192.0.2.1</address>! <port>22</port>! </destination>!</peer>!

•  Defines a reusable collection of nodes

•  Use multiple times –  A modules may use groupings

imported from other modules

•  Refinement

•  Use as structure, record, or object


YANG Example:!!choice transfer-method {! leaf transfer-interval {! description "Frequency at which file transfer happens";! type uint {! range "15 .. 2880";! }! units minutes;! }!! leaf transfer-on-commit {! description "Transfer after each commit";! type empty;! }!}!

The "choice" Statement

•  Allow only one member of the choice to exist in a valid config datastore

NETCONF XML Encoding:!!<transfer-on-commit/>!


YANG Example:!!anyxml software-version {! description "Number to allow";!}!

The "anyxml" Statement

NETCONF XML Encoding:!!<software-version>! <base>A10.2</base>! <routing>B4.2</routing>! <snmp>C87.12</snmp>!</software-version> !

•  Allows arbitrary XML content to be carried in YANG-based models –  Opaque –  Limited operations

•  Bulk only


The "rpc" Statement

rpc activate-software-image {! input {! leaf image-name {! type string;! }! }! output {! leaf status {! type string;! }! }!}!

<rpc xmlns="urn:mumble">! <activate-software-image>! <image-name>image.tgz</image-name>! </activate-software-image>!</rpc>!

•  Defines RPC –  method names –  input parameters –  output parameters


The "notification" Statement

YANG Example:!!notification link-failure {! description "A link failure has been detected";! leaf if-index {! type int32 { range "1 .. max"; }! }! leaf if-name {! type keyref {! path "/interfaces/interface/name";! }! }!}!

•  Defines notification –  Name –  Content


Semantic Differentiators • Notice that YANG is modeling the semantics and data

organization – Not just the syntax

Statement! Purpose!unique" Ensure unique values within list siblings"

keyref" Ensure referential integrity"

config" Indicate if a node is config data or not"

default" Supply default value for leafs"

error-app-tag" Define the tag used when constraint fails"

error-message" Define the message used ...."

mandatory" Node must exist in valid config datastore"


Tools •  pyang (http://code.google.com/p/pyang/)”

– Validates YANG – Translates between YANG and YIN (XML) – Generates XSD

•  libsmi – Translates SMI/SMIv2 MIBs to YANG

• Editors/IDEs: – Emacs yang mode: http://www.emacswiki.org/emacs/yang-mode.el – Eclipse plugin:https://github.com/xored/yang-ide/wiki

• OpenDaylight Yang Tools: – https://wiki.opendaylight.org/view/YANG_Tools:Main

Yang in OpenDaylight


What Should and SDN Controller Look Like?

•  A platform for deploying SDN applications

•  Provide (or be associated with) an SDN application development environment.


SDN Controller: Platform Requirements

•  Flexibility: –  Accommodate a variety of diverse applications –  Controller applications SHOULD use a common framework and programming model,

and provide consistent APIs to their client

•  Scale the development process: –  No infrastructure code hotspots –  Independent development of controller applications & short integration times

•  Run-time Extensibility & Modularity: –  Load new protocol and service/application plugins at run-time. –  Adapt to data schemas (models) discovered in the network

•  Performance & Scale


SDN Controller: App Development Requirements

•  A domain-specific modeling language to describe internal and external system behavior

•  Modeling tools for the controller aligned with modeling tools for devices

•  Code generation from models: –  Enforce standard API contracts –  Generate boilerplate code performing repetitive and error-prone tasks –  Produce functionally equivalent APIs for different language bindings –  Model-to-model adaptations for services and devices –  Consumption of aligned device models

In the OpenDaylight Project, these requirements are satisfied with YANG (and YANG extensions) and via the YANG tool-chain, manifested

in the MD-SAL


OpenDaylight: SDN Controller Architecture

Controller

Service Adapta1on Layer

Inventory Manager

Base Network Func1ons

Topology Exporter Sta1s1cs

Manager Forwarding

Rules Manager Topology Exporter Topology Exporter

Inventory Manager Inventory Manager

OpenFlow 1.0/1.3 BGP-‐LS PCEP Netconf

Client OVSDB

REST APIs

...

Service Func1ons

PCEP ... Configura1on Subsystem

NETCONF

LISP

Network Devices

Applica1ons Network Applica1ons Orchestra1on & Services

Controller PlaSorm

Southbound Interfaces & Protocol Plugins


OpenDaylight: Software Architecture

Controller Model-‐Driven SAL (MD-‐SAL)

Protocol Plugin

RESTCONF NETCONF

Network Devices Applica1ons

Service/App Plugin

Service/App Plugin

... ... Protocol Plugin

Config Subsystem

Messaging Data Store

Remote Controller Instance

Remote Controller Instance

Network Applica1ons Orchestra1on & Services

Controller PlaSorm

Plugins & Applica1ons

Clustering


Model-Driven SAL: Building the Network View Controller PlaSorm

NETCONF

MD-‐SAL

... BGP-‐LS Topology

Exporter

OpenFlow Topology Exporter

Flow-‐Capable Node Inventory Manager

Model

/Opera1onal /Config

network-‐topo

p1 p2

BGP-‐LS BGPv4 BGPv6

nodes links prefixes

n1 n2 nx l2 l1 ... ... lx ... px

OpenFlow

nodes

BGP-‐LS Protocol Plugin

Groups

Table/1

Flow/2

Table-‐stats

Sta1s1cs Manager

Model Model Model

nc:1 nc:2

Flow-‐stats Flow-‐stats

of:1 of:2 Of:n

...

Tables Meters

Table/2 Table/n

Flow/1 Flow/n ...

Ports


Controller

MD-SAL Details

MD-‐SAL

Data Store DOM Broker BA-‐BI Connector

Mapping Service

Codec Registry

Schema Service

Codec Generator

Binding-‐Aware Broker

Binding-‐Aware to Binding-‐Independent Data Transla5on

Binding-‐Aware Plugin Binding-‐Independent

Plugin/Client (Netconf/Restconf)

Forwarding Rules Manager, Stats Manager, BGP-‐LS/PCEP

External Clients


Building a Plugin/Application

Model Model Yang Model

Java API Defini1on Java API Defini1on Generated API Defini1on

Module Implementa1ons

Yang Tools

“Plugin” OSGI Bundle

1

4

Generate APIs

Create Plugin Bundle Deploy

Maven Build Tools

Module Implementa1ons Plugin source code

“API” OSGI Bundle

Maven Build Tools

2

3

Create API Bundle

4 Deploy

Controller


ODL Yang Resources •  YangTools main page:

–  https://wiki.opendaylight.org/view/YANG_Tools:Main

•  Code Generation demo –  https://wiki.opendaylight.org/view/Yang_Tools:Code_Generation_Demo

•  Java “Binding Specification”: –  https://wiki.opendaylight.org/view/YANG_Tools:YANG_to_Java_Mapping

•  DLUX •  Main page: https://wiki.opendaylight.org/view/OpenDaylight_dlux:Main •  YangUI: https://wiki.opendaylight.org/view/OpenDaylight_dlux:yangUI-user

•  Controller: –  Swagger UI Explorer:

•  http://localhost:8181/apidoc/explorer/index.html –  DLUX (YangUI):

•  http://localhost:8181/dlux/index.html


ODL Netconf Resources

•  Config Subsystem: –  How to configure the Netconf connector (client):

•  https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf –  Netopeer installation

•  https://wiki.opendaylight.org/view/OpenDaylight_Controller:Config:Examples:Netconf:Manual_netopeer_installation

•  Netconf test tool: –  https://wiki.opendaylight.org/view/OpenDaylight_Controller:Netconf:Testtool

Thank You

Engineering

Yang in OpenDaylight