摘要

  • 第 19 版草案定义的是两个相互独立、可选实现的功能：link-flap-suppression 延迟传播短时载波变化，dampening 用指数衰减的 penalty 记住较长时间内的反复掉线。
  • down 定时器运行时，底层链路可能已经 down，而接口仍对上层报告 up；因此未翻转的 oper-status 不能单独证明物理载波稳定。
  • feature 宣告、配置受理、运行值、定时器/惩罚状态、接口状态、协议邻接、RIB/FIB、数据包、业务结果与复发窗口必须逐层核验。

被模型诚实暴露的时间差

第 19 版草案 最值得运营人员注意的，不是四个阻尼参数，而是只读节点 timer-running。它取值为 down 时，模型明确表示：底层链路已经 down，接口状态却仍报告 up；取值为 up 时则相反——载波已经回来，但接口尚未向上层宣布恢复。

这不是监控错误，而是控制本身。草案把短时机制命名为 link-flap-suppression，并没有定义一个叫 carrier-delay 的 YANG 容器。down 和 up 两个毫秒值分别约束掉线与上线必须连续维持多久才传播。前者可给光层自动保护留出切换时间，但草案同时承认代价：在这段等待中，流量可能进入黑洞，路由重收敛也会推迟。后者像去抖器，要求信号持续存在且无错，避免一个瞬时恢复立刻把不稳定链路送回业务。

如果变化在窗口内反转，上层可能完全看不到事件，oper-status 与 last-change 都不改变。然而 carrier-transitions 应继续记录底层从 up 进入或离开 up 的次数。于是“接口六小时未变”与“载波期间抖动数次”可以同时为真。缺少计数器、定时器方向与时间戳的状态面板，只呈现了经过政策过滤的现实。

阻尼不是更长的同一个定时器

独立 feature dampening 保存跨事件的记忆。底层每次 up→down 增加 1000 penalty；half-life 决定该值经过多少秒减半；达到或越过 suppress 后，接口被保持在 operationally down；当底层已经 up 且 penalty 降到 reuse 以下，才可解除抑制；max-suppress-time 则限制没有新惩罚时最长被压制的时间。

这些值表达的是风险偏好。较长半衰期让过去的失败更久影响现在；较低 suppress 更早隔离抖动，也更可能延长一次可恢复故障；较低 reuse 要求更长静默期；较大的最长抑制时间把稳定全网控制面的成本更多交给本地业务。草案示例中的 60、750、2000、240 和 penalty 2480 只是例子。presence container 还允许设备以厂商/设备特定默认值启用，所以审计必须保留实际生效值，不能只记“dampening enabled”。

短时 suppression 和长期 dampening 可以同时使用，却不能合并成一个“链路抖动告警”。定时器结束，只说明某次持续性检查结束；suppressed=false，只说明本地 penalty 门已打开；告警数量下降，只说明观测到的症状减少。它们都没有回答光模块、纤芯、供电、远端端口或中间传输为何变化，也没有保证变化不会再次出现。

YANG Library 的边界停在 schema

YANG 1.1 用 feature 让 schema 的一部分成为条件项。两个容器各自受 if-feature 保护，因此设备可以两者皆无、只支持一个或同时支持。RFC 8525 的 YANG Library 列出服务器声称支持的 feature。看到名称，能证明客户端应在该服务器公开的 schema 中期待相应节点；它不能证明某个接口接受了配置，更不能证明硬件事件走过了该逻辑。

NMDA 进一步区分 intended configuration 与 operational state。配置写入可能因为硬件交互、传播时间或本地约束而尚未成为实际使用值。因此，一份完整证据应同时保存候选/意图、服务端回执和随后从 operational 读取的应用值。仅有验证器通过、IESG 状态、feature 宣告或配置成功回应，都不应越级成为运行证明。

Datatracker 主记录 与修订历史 说明第 19 版是 NETMOD 工作组的有效 Internet-Draft，已提交拟作为 Proposed Standard 出版。它们记录规范进程，不记录生产部署。草案安全章节要求 YANG 管理协议使用安全传输、相互认证，并引用 NACM 做访问限制；其模板同时称没有“特别敏感”的单个可写节点。后一句不能被解释为延迟或阻尼配置无害——草案前文已经写出黑洞与延迟收敛的后果。

接口 up 只是恢复核验的起点

RFC 8343 把 oper-status=up 描述为 ready to pass packets。但本草案明确增加了一个例外窗口：报告状态可故意落后于底层载波。定时器结束后，up 仍只是一台设备上一个接口对象的判断，不能代表邻接协议已重建、远端接受了新状态、路径已经重收敛，或业务真的成功。

核验顺序应保留因果时间线。先看载波 transition 与 suppression/dampening 状态，再逐个检查相关协议邻接及重建时间；随后读取 RIB。RFC 8349 中 active route 只表示同一 RIB、同一目的前缀的优选项，并不自动证明 FIB 或硬件表已经写入。下一跳解析、策略、转发表和端口队列都需要独立回执。

最后才是包与业务。RFC 7799 区分主动、被动与混合测量。每个结论都要绑定方向、地址、流量类别、包特征、观测点和时间窗。一个 ping 成功不能覆盖所有 LAG/ECMP 成员、双向路径、不同包类或真实交易。BFD 在部署时可提供快速的路径存活证据，但 BFD session up 也不是应用完成证明。

恢复结论应拆成三句：物理稳定，是目标部件在足够长窗口内不再异常；转发恢复，是目标处理路径上的包被观察到；业务恢复，是应用或客户验收成功。根因消失还要另有维护、光层、供电或其他因果证据。任何一句都不能由 penalty 下降或定时器到期代写。