摘要

  • BIRD 用户希望得到标准 API，不想再靠脚本解析路由守护进程的命令行。
  • Maria Matejka 揭示的难点在更上一层：怎样把多种 Linux 组件的数据模型合成同一个管理界面。

把命令行输出转成 JSON，看上去像是给路由软件补上 API；可脚本一旦依赖某种非标准输出，维护工作就落到了每个使用者手里。BIRD 用户提出了更直接的要求：给路由守护进程一个标准接口。CZ.NIC 的 BIRD 团队负责人 Maria Matejka 在 RIPE 93 上把问题往前推了一步：即使有标准协议，一个由多个软件组件组成的路由器仍然缺少统一入口。

NETCONF 已发展约二十年，用 XML 表示结构化数据，SSH 传输另有规范。RESTCONF 通过 HTTP 提供 REST 风格接口，适合浏览器式的无状态请求。CORECONF 则以 CoAP 和 CBOR 面向受限设备。三者都使用 YANG 数据模型；路由器里的每个软件组件仍维护自己的数据树。

Matejka 举出的 Linux 路由器由 BIRD、NetworkManager 和 systemd 等部分组成。每个组件负责自己的功能，也有自己的数据树。运维人员面对的是一台设备，软件内部却是几套管理面。她在演讲中说，如何把这些树合成一个面向客户的端点，在她介绍的设计里还没有规范。她提到基于 YANG 的解析器和编码器，作为未来代理可能使用的组件。

IETF 文件把若干层次分开定义。RFC 6241 规定 NETCONF 操作和 XML 表示；RFC 6242 规定 SSH 传输。RFC 8040 定义基于 HTTP 的 RESTCONF。YANG 描述数据模型，RFC 7951 与 RFC 9254 分别规定 JSON 和 CBOR 编码。这些文件说明结构化数据如何表达、传送。多个软件组件如何组成同一台路由器的统一数据模型，仍需厂商和运营者决定。

CORECONF 本身也还没有成为已发布标准。IETF Datatracker 将第 21 版标为已过期的 Internet-Draft，最近一次修订在 2026 年 3 月；同一页面列有 2026 年 11 月提交 IESG 的工作组里程碑。对考虑 CoAP/CBOR 的团队来说，当前状态仍然是“过期”。

路由器厂商可以开发代理，把多个组件呈现为单一入口；也可以让运维团队自行对接各套 API。两条路都要回答同一个控制问题：哪个数据模型是权威来源，谁能改它，转换格式时如何保留每个字段的来源。

RIPE 93 演讲和当前草案记录都没有展示一个同时组合 BIRD、NetworkManager 与 systemd 的互操作端点测试；这样的测试才能说明缺少的组合规则已经挡住部署，还是仍停留在设计阶段。

一手来源：RIPE 93 演讲与文字稿 · 官方文字稿 · BIRD 团队页 · RFC 6241 · RFC 6242 · RFC 8040 · RFC 7950 · RFC 7951 · RFC 9254 · CORECONF 草案状态。