YANG by Example

v0.1.1  (2015-­‐11-­‐05)  
Overview  and  Objec.ves  
This  presenta.on  uses  an  example  to  walk  through  all  main  features  
in  the  YANG  data  modeling  language.  
Our  example  uses  standard  and  draA-­‐standard  YANG  modules  for  
sta.c  MPLS  LSPs  with  the  goal  of  crea.ng  valid  configura.on  
AAer  this  presenta.on,  you  should  be  able  to:  
–  Iden.fy  and  describe  common  elements  of  a  YANG  model  
–  Examine  a  YANG  model  and  create  a  valid  configura.on  instance  
YANG  Models  Used  
IETF    Standard  Track  YANG  Models:  
RFC  6991      Common  YANG  Data  Types                                                ieU-­‐yang-­‐types@2013-­‐07-­‐15.yang        
RFC  7277      IP  Management                                                                                        ieU-­‐ip@2014-­‐06-­‐16.yang  
RFC  7224      IANA  Interface  Type                                                                          iana-­‐if-­‐type@2014-­‐05-­‐08.yang  
RFC  7223      Interface  Management                                                              ieU-­‐interfaces@2014-­‐05-­‐08.yang  
 
Dra9  YANG  Models:  
OpenConfig  MPLS  LSP  Model  
                                           

Feel  free  to  download  and  follow!  

Our  Use  Case  –  MPLS  VPN  Configura.on  
Tasks:  
1.  Enable  interfaces  on  routers  
2.  Assign  IPv6  addresses  to  interfaces  
3.  Configure  Sta.c  MPLS  LSPs  

Router 1:
eth0: 2001:db8:c18:1::3/128
Router 2:
eth0: 2001:db8:c18:1::2/128
Task  #1:  Enabling  the  Interfaces  
•  We  start  with  the  Interface  Management  
Model  
•  Examine  model  for  YANG  features:  
–  Structure  
–  Configura.on  and  opera.onal  data  
–  Built-­‐in  and  customer  data  types  
–  Condi.onal  features  
–  Abstract  iden..es  
–  Nodes  references  
Interface  Management  Model  Structure  
RW   interfaces   RO  

string   name   string   name  

interfaces   Interfaces-­‐state  
interface  
iden.tyref   type  
interface  
vang:date-­‐and-­‐.me   last-­‐change  

boolean   enabled   interface-­‐state-­‐ref   Higher-­‐layer-­‐if*  

enumera.on   Link-­‐up-­‐down-­‐  
trap-­‐enable?  

Two  top-­‐level  containers:  

interfaces   interfaces-­‐state  
•  One  entry  per  configured  interface   •  One  entry  per  interface  on  the  device  
•  Contains  all  configura.on  per   •  Contains  all  opera.onal  state  per  
interface   interface  
The  Interfaces  List  
“eth0”   name  
ethernetCsmacd   type  
true   enabled  

enabled   Link-­‐up-­‐down-­‐trap-­‐enable?  

interfaces   interfaces  
string   string   name   “eth0”   “Eth1”   name  
“Eth1”   ethernetCsmacd   type  
iden.tyref   type  
“eth0”  
boolean   enabled   true   enabled  

enumera.on   link-­‐up-­‐down-­‐   enabled   Link-­‐up-­‐down-­‐trap-­‐enable?  

trap-­‐enable  

“Eth3”   name  

ethernetCsmacd   type  
false   enabled  

disabled   Link-­‐up-­‐down-­‐trap-­‐enable?  

The  Model   Example  Instance  data  

The  Module  Header    
RFC  7223    Interface  Management  
Header  Informa.on   module ietf-interfaces {
namespace "urn:ietf:params:xml:ns:yang:ietf-interfaces";
Imports  and  Include   prefix if;
import ietf-yang-types {
Type  Defini.ons   prefix yang;
}
Configura.on  and  Opera.onal     organization
Data  Declara.ons   "IETF NETMOD (NETCONF Data Modeling Language) Working
Group";
Ac.on  (RPC)  &  No.fica.on  Declara.ons   contact
"WG Web: <http://tools.ietf.org/wg/netmod/>
WG List: <mailto:netmod@ietf.org>
...
description
"This module contains a collection of YANG definitions for
managing network interfaces.
...
revision 2014-05-08 {
description
"Initial revision.";
reference
"RFC 7223: A YANG Data Model for Interface Management";
}
 Defining  a  Container  
Container  statement:  
–  Defines  an  interior  data  node  in  the  schema  tree  
–  One  argument  -­‐  iden.fier  
–  No  value,  but  has  a  list  of  child  nodes  in  the  data  tree    
interfaces  
container interfaces {
description
"Interface configuration parameters.”
...
}
Defining  a  List   interfaces  
List  statement:  
–  Defines  an  interior  data  node  in  the  schema  tree.   RW   RO  
–  Single  argument  -­‐  iden.fier,  
–  Represents  a  collec.on  of  entries  –each  entry  consists  of  one  or  more  nodes     interface   Interface-­‐state  

container interfaces{
...
list interfaces {
key “name”;
description
“The list of configured
interfaces on the device.“;
...
}
list interfaces-state{
config false; config false –  Data  under  interfaces-­‐state  is  
key “name”;
description
read-­‐only    
“Data nodes for the operational Config  (RW)  and  State  (RO)  clearly  separated  in  this  
state of interfaces.”
model      
...
}
}
Defining  Leaves   The  Model  
A  leaf  is  defined  by  an  iden.fier  and  has  a  type   interface  
RW  
name   string   interface  
list interface{
key “name”;
description “...”;
iden.fier   name  
leaf name {
type string;
description
“The name of the interface“
}
An  Instance  of  the  Model  
}

interface  
•  Leaf  name  serves  as  list  key   “eth0”   “eth0”  

•  The  type  is  string   Switch  order   “Eth1”   “Eth1”  

“eth0”   “eth0”  
on  graphic  
 YANG  Data  Types  
YANG  has  a  set  of  built-­‐in  types,  similar  to   Use  pattern  ,  range,  and  length  
statements  to  restrict  values    
those  of  many  programming  languages  

–  binary   –  instance-­‐iden.fier     type string {

length "0..4";
–  bits   –  int8,  int16,  int32,  int64   pattern "[0-9a-fA-F]*";
–  boolean   –  leafref   }
–  decimal64     –  string  
–  empty   –  uint8,  uint16,  uint32,  
–  enumera.on     uint64  
–  iden.tyref   –  union  
Leaf  Types  -­‐  Boolean  
Leaf  enabled  with  boolean  value  true  or  false The  Model  
This  is  where  the  interface  can  be  enabled  and  disabled  
interface  
RW  
name   string   name  
list interface{
key “name”; enabled   boolean  
description “...”;
leaf name {...}
         
leaf enabled {
type boolean; An  Instance  of  the  Model  
default "true";
description “eth0”  
name  
"This leaf contains the configured,
enabled   true   interface  
desired state of the interface.”
} name   “Eth1”   “eth0”  

} enabled   true  
“Eth1”  
“eth0”  

name   “eth0”  
enabled   true  
Leaf  Types  -­‐  Enumera.on  
Leaf  link-up-down-trap-enable  may  take   The  Model  
value  enabled  or  disabled RW  
interface  
name   string   name  

enabled   boolean  
list interface{
key “name”; link-­‐up-­‐down-­‐   enumera.on  
leaf name {...} trap-­‐enable?  
leaf enabled {...}

leaf link-up-down-trap-enable {
if-feature if-mib; Switch  order  
type enumeration { on  graphic  
enum enabled {value 1;}
enum disabled {value 2;}
}
description
"Controls whether linkUp/Down SNMP
notifications should be generated”;
}
}
Defining  new  types  
New  types  can  be  defined  using  the  typedef  statement    

typedef percent {
leaf completed {
type uint8 {
type percent;
range "0 .. 100";
}
}
description "Percentage";
}

RFC  6991:  Common  YANG  Data  Types  

•  ieU-­‐inet-­‐types  (ipv4-­‐  and  ipv6-­‐addresses,  domain-­‐name,  etc)    
•  ieU-­‐yang-­‐types  (counters,  gauges,  date-­‐and-­‐.me,  etc)  
 
Condi.onal  Leaves  -­‐  Features  
feature if-mib {
The  feature  statement  is  used  to  mark   description

parts  of  the  model  as  condi.onal   "This feature indicates that the
device implements the IF-MIB.";

The  if-­‐feature  statement  makes  the   reference

"RFC 2863: The Interfaces Group MIB";

parent  statement  condi.onal   ...

}

  list interface{
  key “name”;
leaf name {...}
leaf enabled {...}

This  leaf  is  a  part  of  our  model  only  If   leaf link-up-down-trap-enable {
if-feature if-mib;
the  if-mib  feature  is  supported  in   type enumeration {

the  server  
enum enabled {value 1;}
enum disabled {value 2;}
}
description
"Controls whether linkUp/Down SNMP
notifications should be generated”;
}
}
Abstract  Types  -­‐  Iden.tyref  
The  Model  
identity interface-type { interface  
description RW  
"Base identity from which specific name   string   name  

interface types are derived."; type   iden.tyref  

}

leaf type {
type identityref {
base interface-type; An  Instance  of  the  Model  
}
mandatory true;
description name   “eth0”  
"The type of the interface...."; type   ethernetCsmacd   interface  
reference “eth0”  
name   “Eth1”  
"RFC 2863: The Interfaces Group MIB – “Eth1”  
ifType"; type   ethernetCsmacd  
“eth0”  
} “eth0”  
name  
type   ethernetCsmacd  
The  Instance  Data  in  XML  
Instance  

interface  
“eth0”   name  
interface  
true   enabled  

XML  Representa.on  

<interfaces>
<interface>
<name>eth0</name>
Router 1: <enabled>true</enabled>
eth0: 2001:db8:c18:1::3/128
</interface>
Router 2:
eth0: 2001:db8:c18:1::2/128
</interfaces
Inspec.ng  the  Interfaces  State  Tree  
RO   +--ro interfaces-state
+--ro interface* [name]
string   name  
Interfaces-­‐state   +--ro name string
vang:date-­‐and-­‐.me   last-­‐change   +--ro type identityref
+--ro admin-status enumeration
interface-­‐state-­‐ref   Higher-­‐layer-­‐if*  
+--ro oper-status enumeration
+--ro last-change? yang:date-and-time
+--ro if-index int32
+--ro phys-address? yang:phys-address
+--ro higher-layer-if* interface-state-ref
+--ro lower-layer-if* interface-state-ref
+--ro speed? yang:gauge64
+--ro statistics
+--ro discontinuity-time yang:date-and-
Each  entry  in  the  interfaces-­‐state  list  is  a   time
+--ro in-octets? yang:counter64
container  represen.ng  the  state  of  an   +--ro in-unicast-pkts? yang:counter64
+--ro in-broadcast-pkts? yang:counter64
interface   +--ro in-multicast-pkts? yang:counter64
+--ro in-discards? yang:counter32
+--ro in-errors? yang:counter32
+--ro in-unknown-protos? yang:counter32
…
Imports  and  Includes  
...
import ietf-yang-types {
prefix yang;
}
...

YANG  structures  data  models  into  modules  and  submodules.    

•  The  import  statement  makes  defini.ons  from  one  module  available  inside  
another  module  or  submodule  
•  The  include  statement  is  used  to  make  content  from  a  submodule  
available  to  that  submodule’s  parent  module,  or  to  another  submodule  of  
that  parent  module.  
Example  Import  
ieD-­‐yang-­‐types.yang  
typedef date-and-time {
type string {
pattern '\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}(\.
import ietf-yang-types { \d+)?'
prefix yang; + '(Z|[\+\-]\d{2}:\d{2})';
} }
... description
"The date-and-time type is a profile of the ISO
leaf last-change {
8601 standard for representation of dates and
type yang:date-and-time; times using the …
description
"The time the interface entered its current operational
state. If the current state was entered prior to the
last re-initialization of the local network management
subsystem, then this node is not present.";
reference
"RFC 2863: The Interfaces Group MIB - ifLastChange";
}
Example  derived  type  
Model   Instance  
“eth0”  
Interfaces-­‐state   RO   Interfaces-­‐state   2015-­‐05-­‐19T16:39:57-­‐08:00  
string   name  
interface   interface  
last-­‐change   “Eth1”  
interface   vang:date-­‐and-­‐.me   interface  
interface   interface   2015-­‐05-­‐19T16:39:57-­‐08:00  

interface  
“eth0”  
2015-­‐05-­‐19T16:39:57-­‐08:00  

typedef date-and-time {
type string {
pattern '\d{4}\d{2}\d{2}T\d{2}:\d{2}:\d{2} 2015-05-19T16:39:57-08:00
(\.\d+)?'+ '(Z|[\+\-]\d{2}:\d{2})';
}
Referencing  Another  Leaf  -­‐  leafref  
Use  leafref  to  reference  a  par.cular  
leaf  instance  in  the  data  tree  
RO  

interfaces-­‐state   string   name  

typedef interface-state-ref {
interface   vang:date-­‐and-­‐.me   last-­‐change  
type leafref {
path "/if:interfaces-state/ interface-­‐state-­‐ref   higher-­‐layer-­‐if*  
if:interface/if:name";
}
...
RO  
} “eth0”   name  

interfaces-­‐state   2015-­‐05-­‐19T16:39:57-­‐08:00   last-­‐change  

leaf-list lower-layer-if {
“eth0”  
type interface-state-ref;
“vlan0”   “vlan0”   name  
…
} 2015-­‐05-­‐19T16:39:57-­‐08:00   last-­‐change  
“eth0”   higher-­‐layer-­‐if*  
Task  #2:  Assigning  an  IPv6  Address  
name  
ieD-­‐interfaces.yang  
string  
interface  
iden.tyref   type  

boolean   enabled   To  assign  IP  address  we  need  to  

Link-­‐up-­‐down-­‐trap-­‐enable?  
augment  ieD-­‐interfaces.yang  
enumera.on  
with  ieD-­‐ip.yang  

ieD-­‐ip.yang  
boolean   enabled?  

IPv6  
address  
inet:ipv6-­‐address-­‐no-­‐zone   ip  

uint8   prefix-­‐length  
Augmen.ng  the  Interface  Defini.on  
ieU-­‐ip.yang        
import ietf-interfaces {
prefix if;
} interface  
…

augment "/if:interfaces/if:interface" {
description
"Parameters for configuring IP on
interfaces...";
container ipv6 {
presence
"Enables IPv6 unless the ’enabled’ leaf
(which defaults to ’true’) is set to
IPv6  
’false’";
description
"Parameters for the IPv6 address
family.";
}
}
The  IPv6  Model  
boolean   enabled?  
IPv6  
address   inet:ipv6-­‐address-­‐no-­‐zone   ip  

container ipv6 { uint8   prefix-­‐length  

leaf enabled {
type boolean;
default true;
description "Controls whether IPv6 is enabled or disabled...";
}
list address {
key "ip";
description "list of configured IPv6 addresses on interface.";
leaf ip {
type inet:ipv6-address-no-zone;
description "The IPv6 address on the interface.";
}
leaf prefix-length {
type uint8 { range "0..128"; }
mandatory true;
description "The length of the subnet prefix.";
}
}
)
The  Instance  Data  in  XML  
interface   “eth0”   name  
interfaces   “eth0”  
true   enabled  

boolean   2001:0db8:c18:1::3   ip  
IPv6  
 address   2001:0db8:c18:1::3   128   prefix-­‐length  

<interfaces> Router  #1   <interfaces> Router  #2  

<interface> <interface>
<name>eth0</name> <name>eth0</name>
<enabled>true</enabled> <enabled>true</enabled>
<ipv6> <ipv6>
<enabled>true</enabled> <enabled>true</enabled>
<address> <address>
<ip>2001:0db8:c18:1::2</ip> <ip>2001:0db8:c18:1::3</ip>
<prefix-length>128</prefix-length> <prefix-length>128</prefix-length>
</address> </address>
</ipv6> </ipv6>
</interface> </interface>
</interfaces </interfaces
Task  #3:  Configure  an  LSP  
 
 Task  #3:  Configure  LSPs   mpls  

lsps  

Container  static-lsps  will  hold  our  configura.on   sta.c-­‐lsps  

RW  
  label-­‐switched-­‐path  
name  
next-­‐hop  
Please  note  the  uses  statement  below   ingress   incoming  label  

  push-­‐label  
egress  

next-­‐hop  
incoming  label  
container mpls {
push-­‐label  
presence "top-level container for MPLS config and state";
...
container lsps {
description "LSP definitions and configuration";
container static-lsps {
description "statically configured LSPs, without dynamic signaling";
uses static-lsp-main;
}
}
}
 Groupings   RW  
name  
label-­‐switched-­‐  
next-­‐hop  
Groups  of  nodes  can  be  assembled  into  reusable   path  
ingress   incoming  label  
“eth0”  
collec.ons  using  the  grouping  statement.   “eth0”   push-­‐label  
  “eth0”  
“eth0”  
egress  

A  grouping  defines  a  set  of  nodes  that  are  instan.ated   next-­‐hop  

with  the  uses  statement:   incoming  label  

push-­‐label  
 

grouping static-lsp-main { grouping static-lsp-common {

list label-switched-path { leaf next-hop { type inet:ip-address; }
key name; leaf incoming-label { type mplst:mpls-label; }
leaf name { type string; } leaf push-label { type mplst:mpls-label; }
container ingress { uses static-lsp-common; } }
container egress { uses static-lsp-common; }
}
}
The  Instance  Data  in  XML  
mpls   lsps  

sta.c-­‐lsps  
label-­‐switched-­‐path  
name  
name  
name   Incoming-­‐label  

ingress   100  
next-­‐hop  
egress  
2001:db8:c18:1::2  

<mpls> Router  #1   <mpls> Router  #2  

<lsps> <lsps>
<static-lsps> <static-lsps>
<label-switched-path> <label-switched-path>
<name>lsp0</name> <name>lsp0</name>
<ingress> <ingress>
<incoming-label>100</incoming-label> <incoming-label>100</incoming-label>
</ingress> </ingress>
<egress> <egress>
<next-hop>2001:db8:c18:1::2</next-hop> <next-hop>2001:db8:c18:1::3</next-hop>
</egress> </egress>
</label-switched-path> </label-switched-path>
</static-lsps> </static-lsps>
s</lsps> s</lsps>
</mpls> </mpls>
Summary  
You  should  now  be  able  to:  
–  Iden.fy  and  describe  common  elements  of  a  YANG  model  
–  Examine  a  YANG  model  and  create  a  valid  configura.on  instance  
Back  Maoer  
•  This  material  was  originally  developed  by  Charlie  Justus  and  Carl  
Moberg  with  the  support  of  Cisco  Systems,  special  thanks  to:  
–  Kevin  Serveau  
Changelog  
•  1.0  (2015-­‐10-­‐05)  –  Ini.al  version  
Carl  Moberg  <camoberg@cisco.com>