【侃大山】为啥要有NETCONF？为啥要有YANG？

市场现状

YANG在设备研发领域算是一个相对冷门的分支。不像传统路由策略、BNG业务、较近的SRV6、IFIT那样热门。但是吧，市场集采、达标还都要求这个YANG。真实商用局点呢？有，不算多。还是传统的SNMP+CLI的天下。

那么，为啥设备厂商愿意投入人力搞NETCONF/YANG呢？这篇就是侃大山。随便聊聊。

网管、运营商的意愿

设备厂商我理解是被局点（欧洲局点每次都是先锋）标书推动，同时设备自己也需要一些讲故事的素材和“圆桌”会议上的影响力。注意到国际会议上运营商、网管具有极大的话语权。openconfig就不说了，根本不带设备玩；IETF大会上也是网管为主力。
那么运营商、网管有哪些自己的想法呢？
事实上，在2002年IETF真的一帮网管拉起来开了一场吐槽大会¹。会上分析了当时的网络管理技术，涉及到的有：SNMP、CLI、HTTP/HTML、XML等。分析了它们的优缺点——当然重点是缺点。

• SNMP：用于系统监控还不错，但是标准MIB模块中的配置模型太少。检测质量差，字典序影响性能，批量数据传输性能差。——他们甚至一节写不完，又单独开辟了一个独立章节讲SNMP框架的缺点²。巴拉巴拉。
• CLI：易于使用、不方便自动化，缺少通用数据模型。巴拉巴拉。
• 其他：吐槽太多，巴拉巴拉。

最后，一帮运营商、网管提出了他们对未来网管的33条“需求”。你没看错，33条，要求真多。重点的几条如下：

• 新技术要有全功能覆盖的可编程接口。
  用现在的话说就是：YANG模型要覆盖全量配置、查询，否则CLI的方式重启配置恢复可能会丢配置。
• 要有一套新的数据建模语言，要支持复合数据类型。必须明确区分配置数据和操作数据。
• 基于一个或多个事务发放配置给设备。要支持出错后的设备回滚。
  这里有个引申的理解：要支持无序下发。
• 需要支持人机界面和编程界面。两个接口要保证数据一致性。
• 支持只对部分数据进行操作。支持增量配置。
• 需要减少数据模型与对应操作的不一致。
  这句话很难翻译。原文是：There is a need to reduce the semantic mismatch between current data models and the primitives used by operators.。我的理解：数据模型应该支持的对应的操作，要减少这种不支持的操作。比如：配置数据默认支持的NETCONF基础操作，如果一个config true的节点不支持delete操作，那就是不一致。

理想是美好的，而且网管引入了网络的数据建模、DB回滚的概念。现在看来，大佬们的思路那是相当超前呀。对设备研发而言，说人话就是：上面的这几条，几乎条条都有坑啊！
——就是这些需求，慢慢形成了后来的NETCONF、YANG。
个人总结：
从前，一帮网管大佬在IETF开了个会，吐槽了一堆当时的网管问题。然后发了个会议纪要说：今后我们要搞个新协议，搞个新数据建模语言，然后让网管能管理配置下发、能监控设备、能做各种远程操作，还要能跟CLI行为一致。从此拉开了NETCONF/YANG的序幕。

网管需求是怎么落地的

由上可知，前面各位网管大佬只是提了一堆诉求。那他们，是怎么达成这个目标的呢？

这里讲一个概念：网管管理设备，需要一个“网络管理”的协议，和一个“设备建模”的协议。类比于SNMP和MIB的关系：SNMP负责网管连接设备进行通信、管理网络；MIB则是对设备业务进行数据建模。通过SNMP下发MIB节点的GET操作。
平移到2002年的时候，工作组在吐槽大会上还说了：XML挺好，就基于XML开发标准，用于设备配置和管理吧！于是工作组面临的工作就变成了：需要一个基于XML的“网络管理协议”——这就是后来的NETCONF（Network Configuration Protocol）协议；还需要一个配套使用，而且比MIB更严谨更全面的“数据建模语言”——这就是后来的YANG。

NETCONF

可能是因为之前网管的吐槽几乎都与网管操作有关。于是工作组首先解决的是：网管如何下发操作的问题，于是就有了NETCONF1.0协议。下面这段文字来自网络³，我自己懒得写了：
“NETCONF 协议定义了一种网络配置管理的机制，我们可以通过程序去访问网络设备对外暴露的全量规范的API （application programming interface， 可编程接口）。程序可以使用这种 API 直接发送或者接收全量或者部分的网络配置数据。这是一种远程调用机制（RPC，remote procedure call），控制层和数据交换层都使用 XML。NETCONF 的一个核心理念是几乎覆盖设备管理的方方面面。通过 NETCONF 协议我们可以获取结构化的配置数据或者半结构化的配置数据。”。
我还是说人话：大佬们基于XML定义了一种新的网络配置协议，定义怎么做增删改，怎么做远程调用。但是到底要增删改什么东西？要远程调用什么API？——这个没定义。打个不恰当的比方：我去新东方学习烹饪，叫你怎么颠勺、怎么爆炒，怎么蒸煮；最后，没菜，连个大白菜都没有。这就很有意思了。

YANG

搞完NETCONF的时候，工作组觉得自己已经解决大部分问题了。工作组自己觉得很满意，你们满意不满意我不知道，嘿嘿O(∩_∩)O
新事物的出现往往会有一段高速发展期。既然IETF没有定义这种新API接口长啥样，那么各个头部厂商纷纷提出来自己的建模语言，大家熟知的schema就是在这个背景下诞生的。
Schema和YANG“之争”有点意思：我理解是一个是否要XML化的争论。最后YANG这种类C语言风格的建模语言占了上风。我个人觉得YANG最大的优点就是简洁，类C语言在这个圈子里容易接受。但是这得引入一种新的的YANG编译器。所以又来了一个YIN做转换。转成YIN后，XML格式又可以解析了。又方便设备厂商进行实现了。
这里其实有几个考虑混在一起：
北向接口模型和关联内部表项实现是否应该分层隔离？——废话，当然要
新建模语言如果用XML打底会不会造成某些设备厂商的架构混乱？——当然要避免
XML格式的建模语言就不简洁了吗？ ——仔细想想， < error-type>application< /error-type> 这种error-type出现了2次，的确不够简洁。
全新YANG语言带来的新的编译器的代价这个是显而易见的。
上面这段是我的个人理解，侃大山胡说八道，大家一笑而过，不用太当真。
好，到此，折磨大家的NETCONF/YANG就这么诞生了。

上面的这个工作组叫做NETMOD。
NETCONF后来还出了NETCONF1.1。YANG后来也出了YANG1.1，还出了NMDA，后面有空慢慢讲⁴。

NETCONF/YANG解决了网管吐槽大会中的问题了吗

我把前面我列的几个问题在下面重复一下：

• 新技术要有全功能覆盖的可编程接口。YANG模型要覆盖全量配置、查询，否则CLI的方式重启配置恢复。
  依赖各个设备厂商的实现。
• 要有一套新的数据建模语言，要支持复合数据类型。必须明确区分配置数据和操作数据。
  已解决
• 基于一个或多个事务发放配置给设备。要支持出错后的设备回滚。要支持无序下发。
  依赖各个设备厂商的实现。
• 需要支持人机界面和编程界面。两个接口要保证数据一致性。
  依赖各个设备厂商的实现。
• 支持只对部分数据进行操作。支持增量配置。
  依赖各个设备厂商的实现。
• 需要减少数据模型与对应操作的不一致。
  依赖各个设备厂商的实现。

看见了没？这些问题最终还是要靠厂商实现去解决的。
问题来了——
灵魂拷问——
你所在的设备厂商，这些问题解决了多少？

---

1. RFC3535：https://www.rfc-editor.org/rfc/rfc3535；中文翻译参考：http://rfc2cn.com/rfc3535.html ↩︎

2. RFC3535第4章节：4. SNMP Framework Discussions ↩︎

3. 九净，知乎链接：https://www.zhihu.com/question/40822826/answer/1437540043 ↩︎

4. 这里故意隐去了对应的RFC，怕吓着新人朋友。感兴趣的同学去看：RFC4741、RFC6020、RFC6241、RFC7950、RFC8342 ↩︎