摘要

  • RFC 3139 用“Gold 服务”说明同一全网意图为何要结合拓扑、状态与设备能力，才能变成各厂家设备上的不同本地配置。
  • 多个 translator 可以串联工作，但同一时刻只能有一个对某台设备操作。策略批准、生成候选、写入、反馈与业务效果不能共用一张成功证明。

Gold 先是一项承诺

运营者可以用一句话描述目标：让某组客户获得 Gold 服务。这种抽象让人不必在策略讨论里列出每个队列、过滤器与调度参数。

设备却不认识商业颜色。不同平台可能需要不同分类器、队列编号、带宽参数与命令顺序。主路径与备份路径可能采用不同机制。一次拓扑变化还会改变哪些接口和路由器属于影响范围。

RFC 3139 以此说明高层策略与设备配置的距离。策略描述应该发生什么；它不是本地配置，更不是已安装或已交付服务的证据。

文档于 2001 年 6 月以 Informational RFC 发布。当时多个 IETF 工作组正围绕 COPS/PIB、SNMP/MIB 与特定技术扩展配置方案，人们担心形成彼此割裂的局部优化。1999 年的一次会议没有就若干争议达成共识，于是设计组转而整理任何集成方案都应满足的共同要求。

因此，文中的 MUST 是对未来系统的要求，不证明某种协议已获胜，也不证明当时部署已满足这些要求。

意图到设备之间有三层表示

RFC 3139 区分高层配置管理数据、network-wide configuration 与 device-local configuration。第一层表达网络模型与预期行为；第二层是不属于某一台设备的共同配置；第三层才是针对具体设备的细节。

configuration-data translator 跨越这些层级。它可以是人工、中央软件、中间服务，也可以与设备共置。RFC 定义的是职责，而不是一台固定控制器。

翻译还需要拓扑、设备能力、状态、性能与监控信息。使用旧路径图生成的命令可以语法完全正确，却落在错误设备上。模型里存在的队列功能，也可能不被某台设备当前版本支持。

如果缺少无误转换所需的信息，系统必须识别并采取行动。RFC 没有规定必须停止、等待、缩小范围还是要求人工审批；它拒绝的是把缺失输入默认为确定事实。

全网可以有流水线，一台设备不能有两个同时作者

多个 translator 可以串联：一层把业务目标转成全网配置，一层选择技术方案，一层渲染厂家命令。

到了设备边界，RFC 3139 提出排他规则：同一时刻只能有一个 configuration-data translator 对某台设备操作。全网可以多阶段，设备写入不能存在相互竞争的作者。

这不是完整锁协议。文档没有定义 leader election、lease、fencing 或崩溃恢复，只规定实现必须维护的约束。两个控制器依据不同策略版本或拓扑快照，都可能生成各自合理的候选；交错写入却形成无人意图中的混合状态。

一个控制器降低队列上限，另一个恢复旧 Gold 配置，最终可能留下新版分类器、旧版 scheduler 和丢失的过期时间。两次命令都成功，不代表最终策略一致。

因此文档还要求消除 concurrent shared write access 导致的误配置。收据需要标明 writer、策略版本、输入快照、设备范围与排他时段。last-write-wins 只能决定存储顺序，不能恢复原因。

错误可以发生在两台“各自正确”的设备之间

网络行为经常依赖多台设备共同改变。RFC 3139 要求在必要时，能够同时或同步地添加、修改、删除、导出、恢复完整或部分配置。

“必要时”很重要。部分配置不总是错误；一个未激活对象可以提前安装。但路由先于保护策略生效，可能泄漏流量；入口新标记进入尚未识别它的核心，可能失去服务；只完成一半迁移，可能产生环路或黑洞。

系统要检测包括数据错误在内的失败并恢复，在需要时防止不当部分配置。RFC 3139 没有承诺分布式原子 commit、统一 rollback 或一种 universal partial 定义。

所以必须分别记录 orchestrator batch、设备接受、存储状态、实际应用与流量结果。每个观察者只拥有自己的收据。

事故时的速度来自事故前的准备

文档要求预先下发多份设备本地配置，以便快速切换时不必临时向大量设备下载庞大变更。未来快速，是因为过去完成了准备。

预装不等于激活；激活也不证明候选仍然适用。拓扑、客户与设备能力会在两者之间变化。昨天正确的备份可能成为今天错误的恢复。

配置平台与网络元素冗余也是要求。冗余又引出 writer ownership：谁可写、接管了哪个快照、旧 leader 如何被 fenced。没有排他机制的两个活实例，会重新制造两个 translator。

反馈只能闭合设备环节

设备要返回配置确认、网络状态、监控信息与事件。没有反馈，配置只是单向发布；有了反馈，系统才可以对账。

但“确认”必须带动词：解析、验证、保存 candidate、commit、生效、重启后保留，还是进入 forwarding？不同机制的 success 终点不同。

RFC 3139 要求在 network-wide 上下文中解释本地配置与状态。队列可以按命令安装，却因路径变化而不再满足策略；本地差异也可能恰好是不同硬件实现共同意图的必要方式。

设备反馈仍不是端到端结果。流量可能走另一条路，分类器也可能漏掉客户包。“Gold 已安装”与“客户获得 Gold”属于不同观察点。

配置的权力有时间边界

RFC 3139 要求 effective time 与 expiration time。有些配置必须过期，有些可以永不过期。未来生效的值可以合法但未激活；已经过期的值可以仍留在存储中，却不再有权治理流量。

时钟偏差会放大风险。控制器认为临时例外已经结束，设备却仍在执行。恢复旧快照还可能复活早已过期的规则。

因此收据要包含创建时间、生效时间、过期语义、设备时钟依据、活动状态与实际执行区间。“配置中存在”没有回答“现在是否生效”。

事件驱动配置同样需要事件身份、策略版本、响应 writer 与恢复状态期限。缺少这些信息，快速反馈环可能变成重复振荡。

可追溯性本身就是正确性

RFC 3139 要求访问控制、认证、完整性、重放保护，以及需要时的隐私。host 是最低粒度，用户与角色应能获得不同权限；变更要追溯到主机与用户。

正确语法并不使未授权写入合法。旧策略即使签名真实，也可能过期。认证、完整性、新鲜度与当前授权分别回答不同问题。

发生 drift 时，最终 diff 还不够。调查要找回高层策略、全网投影、输入快照、该设备的 translator、候选、命令响应、错误与下一位 writer 到来前的反馈。

演进不能掩盖语义丢失

系统要容纳数据模型、消息与类型变化，避免破坏互操作或更换大量设备，并复用 MIB 与 SMI 的经验。

新字段可能不被旧 translator 理解；设备可能只支持部分能力；控制器可能省略无法渲染的内容。输出仍可语法有效，意图却已缺失。

安全演进需要 capability discovery、显式未知处理与可见降级。RFC 3139 没有承诺所有旧设备都能执行未来策略。

RFC 3535 所记录的 IAB workshop，以及后来的 NETCONF 与 NMDA，把 datastore、lock、validate、commit、intended/applied/operational 等边界具体化。这些是后续脉络，不能倒推为 RFC 3139 在 2001 年已经实现的功能。

原始教训仍然成立：全网策略可能清晰，本地却无法执行；翻译器可能依据过期事实生成正确语法；设备可能接受而业务没有交付。Gold 从来不是最后一张收据。