Summary

  • IS-IS 个人草案举了一个具体例子：链路信息 TLV 从分片 F1 移到 F2。邻居先收到新版 F1，却还拿着旧版 F2，便可能把一次重新装箱误看成链路删除。
  • 草案用 OGID 标记逻辑更新；当 Fragment Count 大于一时，接收端照常存储并泛洪分片，等相关分片到齐后才更新工程拓扑和运行最短路径计算，等待时间有上限。

字段变长，F1 装不下了，源节点把它移到 F2，再发出两份更新。远端先拿到删去字段的新版 F1，手中的 F2 还是旧版，于是两份里都没有该链路。草案指出，这个短暂拼接状态可能触发重算或隧道迁移；它描述的是协议风险，并没有给出某次真实中断的测量报告。11 月 2 日版本把错误精确定位在“收到半套更新就做决定”的一刻。

提议中的 OGID 是 16 位逻辑事务编号，源节点每次更新都会递增，并把它放在本次生成或重生成的 LSP 分片中。需要协同处理时，源节点设定大于一的 Fragment Count，告诉接收端要等多少个不同分片。接收端并不扣住网络传播：收到的 LSP 仍进入链路状态数据库，照常泛洪，也照常参与数据库同步。推迟的是更高层的使用——流量工程数据库更新与 SPF 计算。分片数凑齐，才一起放行。Fragment Count 为一表示可以立即处理，甚至可能是一项涉及多个分片但无需协同的更新；数字一不能被读成“只改了一片”。

等待有硬边界。第一片开始计时，后来的片不能把时钟重新拨回起点。超时后，接收端释放已有分片，按普通 IS-IS 流程处理。草案的 LRGID 回指帮助迟到的分片补齐它参加过的最近一次多分片事务；连续快速改动如果越过这一次回指，旧事务仍会等到超时。所谓“原子更新”到了这里就要交出真实的故障路径。

旧设备可以按 RFC 8918 忽略不认识的 TLV，继续接收有效 LSP，也就仍可能经历那段假链路消失。IETF 状态页将文档列为个人草案；IANA 的 IS-IS 登记表尚无 OGID 正式编号。若要证明这套机制真的拦住错误迁移，需要不同设备的分片到达顺序、计时器、SPF 结果和实际转发记录连成一条线。