英文原文
https://medium.com/@k.okasha/network-automation-and-the-rise-of-netconf-e96cc33fe28
阅读小记
传统的网络管理主要使用snmp或cli方式，snmp主要用于查询，cli（telnet、ssh）可读取或配置数据。
存在问题：1、cli操作的数据是非结构化的，以编程的方式运行非常麻烦；2、修改设备配置时，需要自定义验证步骤以确保配置正常。
IETF组织2003年时在RFC3535中，对新的网络配置协议提出了新的要求。
- 使用方便
- 配置模式与运行模式进行隔离
- 具备备份与恢复功能
- 提供错误检查功能
这几项要求在传统的网络管理中是做不到的，如果说备份、恢复、错误检查，各大厂商自身的NMS系统或运营商自身的综合管理系统能够封装一二的话，配置模式与运行模式的隔离，则必须需要硬件的自身支持了。而且，基于SNMP、CLI做的封装，其复杂度与面临的问题都是相当庞大。
2006年，NETCONF诞生于RFC4741，NETCONF提要一下功能：
- 区分配置与状态数据
- 多个配置数据库（运行、启动、候选）
- 带过滤的选择性数据检索
-
支持配置事务
其通信模式见下图：
image.png
- 客户端发起请求有两种方式：A、直接与NETCONF PORT的830服务端口建立ssh会话，B、建立SSH会话后请求NETCONF子系统。
- 服务端或代理返回自身支持的功能。
- 最后，客户端通过hello包的形式声明自身功能，然后向服务端或代理发起RPC调用，以查询或修改设备配置。
NETCONF协议栈
image.png
- 使用SSH作为传输协议
- 面向连接和面向会话
- 使用XML编码和表示数据
- 定义了与多个设备交互的操作
- 使用RPC在远程网络设备上调用这些操作
NETCONF标准中并没有定义描述数据的数据结构/模型，所以早期NETCONF使用XML Schema文件模拟NETCONF正在传输的数据。在RFC6020时，YANG模型被标准化，配置和操作数据均使用YANG模块建模。
image.png
设备数据库的几种模式：
- 运行：设备上当前正在运行的配置
- 候选：修改配置但未commit
-
启动：设备启动时使用的配置
image.png
NETCONF真正的力量：
- 如果你需要同时在多台设备上进行配置操作，如添加VPN，向BGP添加地址等，使用NETCONF，可以在所有设备上发送配置，并根据设备上返回的配置信息进行验证，如果一切正常，可以在单个事务中对所有设备的配置操作进行提交。
使用ssh或telnet是永远做不到这一点。 - 另一种情况时，如果对多台设备进行了提交，在运行一段时间后，发现需要还原配置，NETCONF可以让这些设备回滚到其原始状态。
NETCONF是SDN控制器在南向控制网络设备上使用的关键API之一。
