YANG（RFC 7950）是 NETCONF（RFC 6241）的数据建模语言

2003年，IETF成立了一个 NETCONF 工作组，提出一种基于XML的网络配置管理协议 NETCONF(Network Configuration Protocol)，因为该协议的配置功能非常强大，同时兼顾监控和故障管理，安全验证和访问控制，被业界广泛采用配置网络。该协议分为传输层、RPC层、操作层和内容层。其中，内容层是唯一没有标准化的层，于是一种 YANG 建模语言产生了，它的目标是对 NETCONF 数据模型、操作进行建模，覆盖 NETCONF 协议的操作层和内容层。

NETCONF

首先说一下 NETCONF 协议，网络节点上的设备（如交换机、路由器）是需要被配置才能投入使用的，这里说的路由器不是我们家里用的路由器，而是运营商的大型路由器。传统配置这些设备的方式是通过 CLI 手动配置的，其过程如下图所示：
对 YANG 模型的个人理解 - 图1
这些命令需要人工去操作，一行一行输入，如果想要配置远端的若干设备，使用这种方式配置会非常不方便，而且在配置失败的情况下，需要撤销前面所有的操作，总之很不方便就是了。但是如果使用 NETCONF 做同样的事情，其过程如下图所示：
对 YANG 模型的个人理解 - 图2
NETCONF 协议提供一套管理网络设备的机制，用户可以使用这套机制增加、修改、删除网络设备的配置，获取网络设备的配置和状态信息。通过 NETCONF 协议，网络设备可以提供一组完备规范的 API，应用程序可以直接使用这些 API 向网络设备下发和获取配置。总之，NETCONF 给网络管理人员带来了方便，NETCONF 采用的是 C/S 的模式，其结构如下图所示：
对 YANG 模型的个人理解 - 图3
前面提到 NETCONF 协议内部分为传输层、消息层（RPC）、操作层和内容层。内容层没有被标准化，NETCONF 协议本身没有对内容层的数据结构做任何的限定，但是却规定了内容层需要使用 YANG 对其数据进行建模。在 NETCONF 出现之前，我们熟知的协议都是采用在协议中规定报文的结构体，并按字节流读取并解析的架构。这种形式的协议其扩展性和可读性都很差，只要修改协议内容就需要更改代码。比方说我现在编写了一个远程通讯程序，通过网络发送以字节流形式的内容，前两个字节是发送者和接受者的编号，后面的字节是消息，现在我想升级我的协议，在消息前面增加日期的信息，那么我就必须修改协议栈的代码，如果每次都以这种形式升级我的协议，每次都需要去修改协议处理代码。若去修改配置网络设备的协议，甚至需要从硬件上修改才能使设备解析所接受的数据，想想就头大。而 NETCONF 使用了 YANG 来规定数据的模型，只要符合该模型的数据都可以做为其内容层的数据，这样大大提高了协议的扩展性，无非就是把你的 YANG 文件修修改改。

YANG 模型

回到 YANG 模型的概念，YANG ，刚开始我以为这是拼音，直到查找了官方文档我才发现是真的拼音，它的图标就是太极图 ，而与 YANG (阳) 对立的 YIN (阴) 就是 XML —— NETCONF 配置的编码格式，这是因为它能够与 XML 无差错地相互转换（其实我觉得 JSON 等也可以做到），下面是 YIN 和 YANG 相互转换的例子：

player.yang

  1. module player {
  2.     yang-version 1.1;
  3.     namespace "urn:opendaylight:player";
  4.     prefix "player";
  5.     revision "2019-08-03" {
  6.         description "Initial revision of lb-resource model";
  7.     }
  9.     grouping player-property {
  10.         leaf playerID {
  11.             type uint8;
  12.         }
  13.         leaf playerName {
  14.             type string;
  15.         }
  16.         leaf playerGender {
  17.             type enumeration{
  18.                 enum "male" {
  19.                     value 0;
  20.                 }
  21.                 enum "female" {
  22.                     value 1;
  23.                 }
  24.             }
  25.         }
  26.     }
  28.     container player-DB {
  29.         list players {
  30.             key playerID;
  31.             uses player-property;
  32.             leaf password {
  33.                 type string;
  34.             }
  35.         }
  36.     }
  38.     rpc add-player {
  39.         description
  40.           "add player api of rpc";
  41.         input
  42.         {
  43.             uses player-property;
  44.         }
  45.         output
  46.         {
  47.             leaf success {
  48.                 type boolean;
  49.             }
  50.         }
  51.     }
  52. }

player.xml

  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <module name="player" 
  3.     xmlns="urn:ietf:params:xml:ns:yang:yin:1" 
  4.     xmlns:player="urn:opendaylight:player">
  5.     <yang-version value="1.1"/>
  6.     <namespace uri="urn:opendaylight:player"/>
  7.     <prefix value="player"/>
  8.     <revision date="2019-08-03">
  9.         <description>
  10.             <text>Initial revision of lb-resource model</text>
  11.         </description>
  12.     </revision>
  13.     <grouping name="player-property">
  14.         <leaf name="playerID">
  15.             <type name="uint8"/>
  16.         </leaf>
  17.         <leaf name="playerName">
  18.             <type name="string"/>
  19.         </leaf>
  20.         <leaf name="playerGender">
  21.             <type name="enumeration">
  22.                 <enum name="male">
  23.                     <value value="0"/>
  24.                 </enum>
  25.                 <enum name="female">
  26.                     <value value="1"/>
  27.                 </enum>
  28.             </type>
  29.         </leaf>
  30.     </grouping>
  31.     <container name="player-DB">
  32.         <list name="players">
  33.             <key value="playerID"/>
  34.             <uses name="player-property"/>
  35.             <leaf name="password">
  36.                 <type name="string"/>
  37.             </leaf>
  38.         </list>
  39.     </container>
  40.     <rpc name="add-player">
  41.         <description>
  42.             <text>add player api of rpc</text>
  43.         </description>
  44.         <input>
  45.             <uses name="player-property"/>
  46.         </input>
  47.         <output>
  48.             <leaf name="success">
  49.                 <type name="boolean"/>
  50.             </leaf>
  51.         </output>
  52.     </rpc>
  53. </module>

从 YANG 的语言结构可以看出它是一种树形结构的建模语言，通过树形结构的节点定义描述了数据模型的层级嵌套结构以及各属性的数据类型。在 ODL 中通过 yangtools 插件可以将 YANG 模型生成相应的 Java 接口、类及方法等，为 ODL 内部数据处理编程提供了便利。

YANG 的辅助工具

pyang

pyang 是一个 YANG 验证器，转换器和代码生成器，使用 python 编写，它可用于验证 YANG 模块的正确性，也可以将 YANG 模块转换为其他格式，以及从模块生成代码。
SDN、NFV 盛行的今天，YANG 建模语言变得越来越重要，但是 YANG 可以选择的工具却并不多，pyang 就是一个 YANG 的辅助工具，它是由 python 代码编写的 YANG 语法验证器、转换器以及代码生成器。使用 pyang 可以将 YANG 文件转换成 tree、YIN 等其它格式的模型或者数据，下面将会介绍 它的功能和使用方法：

安装

确保你已经安装了 python，然后直接使用 pip 工具下载即可

  1. pip install pyang

如果想在 window 环境下使用，也可以直接去官网下载，下载完成后解压进入目录，然后点击env.sh配置环境后进入bin目录下右键执行在git bash Here，因此你还需要事先安装git等含有 shell 命令行工具（如 powershell, CMD 不行啊），要想在其他目录使用，最好在系统环境变量 PATH 中添加其 bin 目录的路径，打开个Git Bash 命令行后运行pyang -v确认安装是否成功。

使用

它是一个命令行工具，yang-central 有详细的命令介绍，其中常用的命令有：
YANG to tree
由于YANG文件中可能定义嵌套的数据结构，对于复杂的文件不易观察整个文件内的所有数据，pyang -f tree <file-name>命令可以将YANG文件转换成并生成tree文件，正好解决这一的问题：
对 YANG 模型的个人理解 - 图4
可以观察到 tree 文件中有很多符号，如：?、[]、*、rw、ro 等。每个符号的含义都与YANG模型的定义是对应的：

  1. *符号表示此属性是list或者leaf-list类型
  2. []符号中描述的字段，表示是list的key值
  3. rw符号表示此字段是可读可配置的
  4. ro符号表示此字段是可读的，一般为状态属性
  5. ?符号表示此字段是可选的


YANG to YIN
命令pyang -f yin -o player.xml player.yang能够将 YANG 文件转化并输出为 XML 文件，-o <out-file-name> 选项可以定义输出文件名。

YANG 语法校验
使用命令pyang --ietf <yang-file>能够对文件进行IEFT标准的语法校验。

MG-SOFT Visual YANG Designer

另外有一款商业 YANG 模型浏览设计软件MG-SOFT Visual YANG Designer Professional Edition，它能够通过GUI界面设计YANG模型：
对 YANG 模型的个人理解 - 图5

参考