摘要

  • RFC 9003 只允许在 Administrative Shutdown 或 Administrative Reset 的 Cease NOTIFICATION 中附带最多 255 个八位组的 UTF-8 自由文本；它取代了 RFC 8203 的 128 八位组规范。
  • NOTIFICATION 发出后连接立即关闭，BGP 内没有收讫或“正确理解”确认；若传输没有完整性与机密性，文字还可能被伪造或窥视。
  • 解释、排流和保留路由是三个不同控制面。可靠运营要证明线上的原始字节、接收日志、重试决定、RIB/FIB 变化与真实数据包，而不能把工单文字当成远端指令。

凌晨两点，边界路由器按计划结束一条健康邻接。邻网日志出现 [CHG-4281] 边缘升级，预计 30 分钟。值班者不必先在邮件里猜测，这很有价值。

但这行字没有证明谁批准了变更、流量是否提前移走、对端是否保留 stale route、30 分钟是否可信，也没有告诉自动化应继续连接还是停止。它只是与关闭同时到达的一项声明。

标准只给关闭说明一个很窄的入口

RFC 4486 为 Cease 定义多种原因；RFC 9003 只在子码 2 Administrative Shutdown 与子码 4 Administrative Reset 上定义自由文本。maximum-prefix、peer deconfigured、collision resolution、out of resources 等原因仍有自己的结构化分类。不能用一段好听的文字覆盖错误的子码。

编码也刻意简洁：一个八位组记录长度，后面跟等长的 UTF-8；长度为零表示没有说明，字段不以 NUL 结尾，并要求 shortest form。上限是 255 个八位组，不是 255 个字符。中文、日文、阿拉伯文或俄文常以多个字节表达一个字符，这正是旧 128 上限在不同语言间产生实际不公平的原因。

RFC 9003 已取代 RFC 8203，但 128 仍是兼容边界。确认对端实现新规范时才可放心使用 255；未知时应控制在 128 以内。只实现旧规范的对端可能把更长数据记为错误，但仍处理这条终止连接的 NOTIFICATION。

这符合最小初始规格：共同层只规定两个子码、一个长度字节与一种编码。双方无需统一工单平台、语言、披露政策、升级流程或日志期限。互通需要一个载体，不需要中央维护制度。

连接结束后，没有协议内回执

RFC 4271 要求 NOTIFICATION 发出后立即关闭 BGP 连接。接收者即使发现 NOTIFICATION 有问题，也无法再发一条 NOTIFICATION 回报。RFC 9003 因而明确：接收方不能确认已经收到并正确理解关停说明。

所以，“本端已发送原因”的日志只证明本端尝试。抓包可证明某些字节离开接口；对端抓包或 daemon 日志可证明到达和解码。它们仍不能证明值班者看见、查到对应工单、同意预计时间或授权任何动作。

重要事件必须保留带身份的带外记录。共享变更号很合适，因为它把两个证据系统连接起来，而不把内部工单全文倒进 BGP。若编号在双方没有共同含义，它只是一串装饰。

没有回执不意味着应把聊天协议塞进 BGP。纠错、批准和协商属于能做双向认证与持久留存的渠道。终止报文的价值，是在最难搜索这些渠道的时刻留下一个短索引。

UTF-8 合法不等于内容可信

编码验证保护 parser，不验证事实。合法字符串仍可能包含伪造工单、不现实的恢复时间、易混淆 Unicode 字符，或故意伪装成另一行 syslog 的内容。shortest form 排除了非法替代编码，却不能消除视觉欺骗和恶意语义。

RFC 9003 特别提醒，这些文字通常会进入日志。255 八位组只限制规模，不负责净化。接收系统必须转义存储、显式处理控制字符、固定 Unicode 显示策略，并在界面上清楚区分“对端提供的数据”和“本地可信字段”。

传输安全同样关键。没有完整性保护，说明可能被伪造；没有机密性，它可能被旁观。自由文本比普通路径属性更容易泄露工单编号、员工姓名、主机名、客户、拓扑与未经证实的根因。

因此应执行数据最小化。跨组织可核对的编号、宽泛变更类别和时间区间，通常优于内部叙述。不得发送凭证、个人数据、秘密拓扑或未经审核的事故结论，因为对端有权按自身政策存储和转发这些内容。

接收方应把文字标为“对端未核实声明”，直到带外渠道证实。即使 TCP 传输认证正确，也只证明配置端点，不证明写句子的人或句子内容。

解释关闭不等于为关闭排流

最危险的误读，是把礼貌的理由当成优雅维护。RFC 8326 的 Graceful Shutdown 在断开之前对路径降优先级、等待备选收敛，再关闭会话。RFC 9003 的文字属于关闭动作本身，无法把更早的包移走。

成熟流程可以同时使用两者：先排流并验证，再以简短工单号关闭。但两项结果必须独立证明。没有说明不代表排流失败；说明写得很好也不代表排流成功。

终止后的路由状态也并不统一。RFC 8538 给 Graceful Restart capability 增加 N-bit。双方交换后，除 Hard Reset 外的 NOTIFICATION 可触发 stale route 保留；Cease 子码 9 Hard Reset 则请求完整重置。

RFC 8538 建议 Administrative Shutdown 使用 Hard Reset，而 Administrative Reset 留给用户选择，但这不是所有实现都必须采用的固定映射。若 Hard Reset 内携带说明，外层子码是 Hard Reset，内层才是 Administrative Shutdown 或 Reset 及其文本。监控只记录外层，就会丢掉本想保留的原因。

保留 route 也不等于保留 forwarding。stale next hop 可能指向已被维护移除的设备；完整撤销也可能发生在备选路径已经就绪之后。必须分别验证 N-bit、封装子码、stale timer、RIB/FIB 与数据包。

对端保留相信与响应的权力

发送方控制自己的终止动作与附带声明；接收方控制日志、脱敏、告警、重试、stale policy 和升级。这才是实际主权边界。

RFC 4486 建议对 Administrative Shutdown 等可能长期存在的 Cease 原因抑制重连，并限制连续自动重试，最后交给管理员。它避免对一个明确关停的邻居无限敲门，却没有让 30 分钟后回来 这句话远程安装本地计时器。

自动化应以结构化子码和经过认证的本地政策决定动作，再用文字补充上下文。已知工单可丰富事件，未知工单应触发核对，而不能执行。预计时长可帮助人判断，机器仍须遵守自己的依赖与客户风险边界。

分类错误也要报警。永久去配置却标为 Reset，可能造成无穷重试；短暂 Reset 却标为 Shutdown，可能压制正常恢复。自由文本能让错误听起来合理，控制面最终仍依赖结构化状态。

从原始字节证明到数据包

验收先定义谁能生成对端可见文字、共享工单命名空间、允许原因、八位组预算与禁止数据。准备已知编码长度的 ASCII 和多字节 canary；对未知能力的邻居测试 128 安全边界，只在双方已证明支持时测试更长值。

发送时记录会话端点、时间、error code、subcode、长度、原始字节和 UTF-8 解码。使用 Graceful Notification 时还要记录双方 N-bit，以及 Hard Reset 是否封装行政说明。CLI 截图是意图，报文与 daemon 状态才更接近事实。

接收时把原始值与安全渲染值分开保存。确认非法序列不会被解释，控制字符被限制，长消息按预期处理，工单能链接到已授权通知。检查 syslog、telemetry、告警去重、保留与脱敏；任何能冒充本地字段的对端文本都应判失败。

最后离开文字层：记录 socket 关闭、FSM 转移、重试、withdraw 或 stale 标记、stale timer、RIB、FIB next hop 与流量。只有这条完整链才能说明维护既被解释，又被安全执行。

回滚也必须精确。可以关闭自由文本、缩至 128、退回受控词表或只发工单键；不得因此掩盖真实 Cease 分类或丢弃带外证据。减少危险表达，不等于恢复无信息时代。

这项标准的价值恰在克制：会话消失时能留下一个可互通的线索。线索只有被授权、最少披露、外部核验和运行事实包围，才会变成可靠证据。解释关闭的权力确实存在，但它从未包含规定他人如何理解。