一、YANG基础

 1. 什么是YANG?

     YANG 是随着 NETCONF 协议而产生的数据建模语言，由RFC6020定义，类似于XML Schema和SNMP的SMI， 具有良好的可读性和可扩展性。其关键特性：      

● 服务和网元数据模型vs信息模型（UML）
    - YANG是数据建模语言
● 领域专用语言
    - 专为网络配置而生
● 网元配置建模
    - Yang is rich enough to model NE configuration (often follow the CLI)
● 服务配置建模
    - Yang is rich enough to model services in the same language as the NE
● 网络拓扑建模
    - 通过发布YANG来可以支持任何新设备
● 设备厂商必须通过IETF创建和发布自己设备的杨模型 

需要解释一下数据模型和协议的关系：

        什么是数据模型？一个数据模型明确和精确地确定数据的结构、语法和语义；那协议呢？ 用于查看和操作数据的远程原语（例如：XML RPC或HTTP方法）；对数据模型定义的数据进行编码（例如：XML或JSON）

        YANG Concepts

 2. 为什么会出现YANG?

     首先从NETCONF的出现说起，它是一种网络配置协议，该协议的产生起源于网管的一次用户体验吐槽大会，在会上提出了网络管理中的14个问题：

     (1). 从操作员的角度来看，易用性是任何网络管理技术的关键要求；

     (2). 必须明确区分配置数据、描述操作状态的数据和统计数据；

     (3). 需要能够从设备中提取单独的配置数据、操作状态数据和统计数据，并能够在设备之间进行比较；

     (4). 必须使操作员能够集中于整个网络的配置，而不是逐个设备配置；

     (5). 支持在多个设备上配置事务，以简化网络配置管理；

        -- 服务和网络管理，而不仅仅是设备管理

     (6). 假定需要进行配置 a和配置 b，应该能够生成从a到b所需的操作，以便使得状态变化对网络系统产生最小的影响。将配置更改所造成的影响降到最低是很重要的。

     (7). 备份和恢复配置的机制是操作人员需要的原始操作。

        -- 配置数据的导入导出

     (8). 为了在两个配置之间确定变化以及这些配置是否一致，必须很容易地对配置进行一致性检查。

        -- 一致性检查

     (9). 基于文本的配置，如差异化和版本管理工具，如RCS或CVS，可以用来处理配置，这意味着设备不应任意重新排序数据，如访问控制列表

        --基于文本进行配置  

    (10). 网络范围的配置通常存储在中央主数据库中，并转换成可被推送到设备的格式，通过生成CLI命令序列或将完整的配置文件推送到设备上。没有共同的数据库模式……尽管各种操作符使用的模型可能非常相似。

         提取、记录和规范这些网络范围的配置数据库模式的公共部分是可取的。

        --标准化数据模型

     (11). 区分配置的分布和特定配置的激活是很重要的。设备应该能够容纳多种配置。

        --支持多种配置集

     (12). Typical requirements are a role-based access control model and the principle of least privilege, where a user can be given only the minimum access necessary to perform a required task.

     (13). It must be possible to do consistency checks of access control lists across devices.

     (14). SNMP access control is data-oriented, while CLI access control is usually command (task) oriented. … As such, it is a requirement to support both data-oriented and task-orientedaccess control

         --支持基于角色的配置 ROLE-BASED Access Control

     为解决这些问题，NETCONF历经多年的讨论，最终产生了一系列的标准：

     (1). RFC4741- 4744 分别描述了NETCONF在三种不同的传输模式SOAP，BEEP和SSH下是如何工作的。

     (2). 2008 年7 月推出RFC5277，主要定义了NETCONF的事件通知机制，用于故障管理。

     (3). 2009 年5 月推出的RFC5539 描述了NETCONF如何保证传输层传输信息的安全机制，加强了NETCONF的安全体系。

     (4). 2010年，RFC 6020 为NETCONF的YANG建模语言

     (5). 2010年，RFC 6021 通用YANG的数据类型

     (6).  2011年6月RFC6242更新了基于 SSH 的传输模式。NETCONF 协议是完全基于XML 之上的，所有的配置数据和协议消息都用XML 表示。

     (7). 2011年，RFC6244 使用NETCONF和YANG的网络管理构架；

    再次网络设备配置的实践角度来说，让你配置一台设备，你直接CLI敲命令就可以了，如果让你配置10台、100台设备你会怎么去做，你肯定会去想有没有这样的方法，可以使用极少的步骤统一配置下发，甚至一键下发。进一步来讲，如果这100台设备又分属不同的厂商，厂商或多或少有些差别，难度又加大了。以下两部分摘自知乎，讲得比较好，易于理解。   

 网络设备的配置结构往往是是不同的。实现同样的功能的不同设备需要的配置结构也往往不同。比如思科设备接口上配置一个address 只要知道接口名 ip版本 和地址掩码就足够了 但是juniper的机器上不但要知道这些还要额外提供一个unit 号来标识逻辑接口。特别是现在nfv大潮下，nfv是干毛的，网络功能虚拟化，既然虚拟化我就更关注的是功能本身而不是实现这个功能的设备，对于管理人员来说，他往往就只想告诉一套nfv系统，我要什么功能，比如 我要一号站点能联网我要DHCP服务我要VPN，而单纯利用netconf是无法配置的，因为还要求具体的配置结构。这可咋整！

没事儿，我们只要给对应的设备所需的配置结构来个模型不就行了？到时候不就是完形填空吗，yang model就是吃这口饭的，我只需知道对应设备的yang model就可以向管理者请求对应设备所需的信息了，具体结构上的问题有yang model来解释。

什么叫做结构上的问题呢？还是举刚才那个例子

思科为啥不需要unit号来指定逻辑端口呢？因为它的逻辑端口藏在接口名里

所以它的配置类似这样

接口名{
    ip{
        address x.x.x.x
        mask x.x.x.x
    }
}
但是juniper的额外需要一个unit号来表示逻辑端口

所以它的配置类似这样

接口名{
    unit x {
        ip{
            address x.x.x.x
            mask x.x.x.x
        }
    }   
}
当然实际上他们的yang model 要比这个复杂的多，比如juniper还有family 这个层级这里就是举一个例子

但是对于上层用户管理来说，他只用填逻辑口号，接口名，地址以及ip版本就可以了，他不需要知道具体到底实际的配置长啥样了，因为有可能及其复杂233.

是不是感觉很完美了，这样NFV可以让服务提供商随意换设备了，底层是思科华为还是juniper没啥所谓，反正只要有yang model我们就知道到底怎么配一台机器了。

XML呢，刚说过netconf是一种协议，它实际是个服务器，接受客户端发来的请求来配置自己，所以每台设备上都有一个netconf server，这里的信息交互就是用xml来实现的，所以yang model其实就是一种描述XML结构的模型。

简单而言，支持netconf的设备其实就是有了一套有标准的设备API。
这套API不光能够做配置，还能提交一些本来由CLI实现的命令。
本质上，netconf协议交换的是XML，传输的是一个一个的RPC。
你只需把你需要的配置，按照你设备上的netconf模型写一个xml，通过一个netconf client 发送给设备，设备就可以去给你配置，并把配置的结果返回给你。

传统我们做自动配置脚本，都是基于ssh连接到设备上，然后一条一条命令去输入，这种脚本局限性很大，搞成模板替换数据也是很费神的一件事儿。有了netconf这些都会成为历史，只需整体写一个xml模板，然后因为它是xml，所有很多python的模板包都可以轻轻松松拿来用，比如jinjia template。 然后，因为你的配置是整体发送过去的，也就不用一条条命令来看执行结果，处理那些讨厌的问题， 比如突然某一条失败了，配置要回滚。。。

更棒的是，netconf 对不同的配置结构都是通过统一的模型语言来描述的，也就是yang model，大部分的配置结构都可以用yang model来描述，理论上你要是有目标主机的yang model，连配置模板也可以自动生成。。。如果你给你的脚本加个fancy的GUI，那么恭喜你，你完成了一个SDN的雏形。

     SNMP--网络监控协议；NETCONF--网络管理协议；OpenFlow--网络控制协议；

3. 为什么不使用XML Schema Language?

    XML Sechema 也可以进行XML的检验，但不易于操作员来阅读，而YANG可读性好、简单、直接、可扩展；

 二、YANG在OpenDaylight中的使用

      YANG在OpenDaylight中也用来做为建模语言，MD-SAL中M即是YANG。

三、YANG的未来

      YANG的使用已不局限于NETCONF

四、YANG学习资料链接：

1. YANG工具：http://www.yang-central.org/twiki/bin/view/Main/YangTools 

2. yang模型理解http://www.sdnlab.com/18066.html

3. ODL中拓扑展现功能总结 http://www.sdnlab.com/18534.html

4. ODL中拓扑展现功能总结(二)http://www.sdnlab.com/18730.html

5. SDN网络与传统网络对比分析 http://www.sdnlab.com/18725.html

本文参考互联网相关资料整理

从零开始学OpenDaylight之六：YANG