Netconf <edit-config>操作属性排序实现机制咨询

传统非事务模式的实现方式 #

你之前的理解在非事务型网管场景下是完全成立的：

• 面对没有事务配置能力的设备，不管用SNMP SetRequest、还是非事务实现的NETCONF edit-config接口，NMS必须拆分配置为两个独立PDU：第一个PDU只携带属性X的配置值，等设备返回X配置成功的应答后，再构造第二个PDU下发属性Y的配置。
• 这种模式下NMS侧需要自己维护全量配置项的依赖关系表，还要手动处理下发失败的回滚（比如X下发成功Y失败时，要主动把X改回原值），不同设备版本的顺序规则有差异时还要做单独适配，维护成本非常高。

ConfD等事务型框架无需NMS处理顺序的核心原理 #

ConfD提到的NMS无需关注下发顺序，本质是把配置顺序、错误恢复的逻辑全部从管理端转移到了设备侧的事务配置框架里实现，靠多阶段事务提交流程解决顺序问题，不需要NMS拆分请求、控制排列顺序。
ConfD官方文档的相关表述如下：

从设计视角来看，诸如“特定参数必须在同一命令行指定”“参数必须通过独立PDU发送”“属性X必须先于属性Y下发”这类要求，都是管理端向设备传递配置意图流程中无意义的瓶颈。在事务型接口的支撑下，网络管理应用无需处理配置的序列化、下发排序以及错误恢复逻辑；配合NETCONF这类适配性良好的编码协议，完整的配置意图可直接传递至设备，无需拆分为多条独立命令执行。

具体的实现逻辑拆成4步，全程不需要NMS参与顺序控制：

• 第一步：全量配置暂存。NMS可以把X、Y的配置放在同一个edit-config请求里发给设备，ConfD不会收到一个配置项就立刻修改运行态，而是把所有收到的配置全部存入*候选配置数据库（Candidate Datastore）*暂存，这一步完全不感知X和Y在请求报文中的排列顺序。
• 第二步：依赖解析排序。设备侧基于YANG模型定义的配置依赖、或者内部预置的生效优先级规则，自动对暂存的全量配置做拓扑排序：比如识别到属性X必须先于Y生效，就自动把X的生效操作排在Y前面，这个排序逻辑完全在设备内部完成，对NMS透明。
• 第三步：原子提交生效。框架按照排好的顺序批量把配置应用到运行态，如果中间任意一步失败（比如Y配置校验不通过、生效失败），整个事务会自动回滚，把已经修改的配置全部恢复到提交前的状态，不会出现部分配置生效的中间态。
• 第四步：统一结果返回。整个事务要么全部成功、要么全部失败，最终统一给NMS返回提交结果，NMS不需要处理中途的异常回滚逻辑。

关键认知澄清 #

• 这个能力不是NETCONF协议天生自带的，核心是设备侧的事务配置框架实现的：如果设备的NETCONF实现没有候选库、没有多阶段事务机制，收到配置节点就直接改运行态，那还是需要NMS手动拆分PDU控制顺序。
• 传统SNMP场景下基本都需要NMS控顺序，本质是绝大多数SNMP Agent没有实现事务配置机制，SetRequest收到后直接修改运行态，没有暂存、排序、原子回滚的能力。

内容的提问来源于stack exchange，提问作者Mohan