摘要

  • RFC 9785 的 Highest-Preference 与 Lowest-Preference 只在候选 PE 之间确定次序，而且规范明确假定候选者已经具备接任条件。
  • 候选资格、管理偏好、对外通告的在用偏好、DF 结果、BUM/单播转发、收敛和客户结果是不同事实。
  • Don't Preempt 能减少恢复后再次切换的扰动，但可能让已经不再是管理首选的现任 PE 继续担任 DF。

一个数字只能承担一种含义

按照 RFC 7432，All-Active 多归属场景中的 DF 负责向多归属设备或网络发送广播、未知单播和组播；Single-Active 场景还包括单播。RFC 8584 把 DF 选举拆成 PE 发现、候选表维护和获胜者计算。

RFC 9785 在这个框架上加入了管理员可以直接理解的顺序。算法 2 选择数值最高的 Preference，算法 3 选择数值最低者。该字段长两字节，范围 0 到 65535，默认值 32767。IANA 登记表 同时记录了这两个算法和 Don't Preempt 的 D 位。

它解决的是“候选者应该按什么顺序接任”。规范的要求没有说偏好产生就绪性；相反，它写明这一排序建立在各候选 PE 已经 operationally ready 的假设上。因此，Preference=500 是一条管理意图，不是端口探针、表项回执或客户流量样本。

先证明进入候选表，才谈得上排名

当 Highest/Lowest Preference 与 AC-DF 联用时，只有相应的 Ethernet A-D per ES 和 per EVI 路由已经收到，PE 才进入特定 ES/Tag 的候选集合。这条规则能阻止一个缺少必要连通性通告的 PE 仅凭高偏好获胜。

但候选资格仍停留在控制面。它没有观察硬件或软件转发表是否已下发，也没有测量 BUM 复制是否到达正确 attachment circuit。RFC 7432 甚至专门处理选举尚未稳定时两个 PE 都认为自己是 DF 的瞬态。分割视界能约束环路，却不能证明切换没有丢包或重复。

算法一致性也是输入。如果同一 Ethernet Segment 上有人通告 Highest-Preference、有人通告 Lowest-Preference，所有 PE 必须回退到 RFC 7432 的默认算法。只保存“PE2 是 DF”，就丢失了究竟是偏好算法获胜还是配置冲突后的 fallback。

本地策略还可以依据核心带宽、端口状态等事件动态调整 Preference，不过 RFC 9785 明确把具体策略留在范围之外。标准传送策略结果，并不验证触发它的检测器是否可靠。

非回切让配置值和在用值同时成立

设 PE3 原本偏好最高，故障后 PE2 接任。PE3 恢复时，如果立即按配置重新夺回 DF，就会制造第二次数据面变化，可能带来一次不必要的丢包。Don't Preempt 的用途正是保留 PE2。

恢复中的 PE3 先等待 boot-timer 或 hold-timer，收集其他 PE 的 Ethernet Segment 路由，再选择参考 PE。若其行政偏好足以压过现任者，它可以继承参考 PE 的 operational in-use Preference，并以 DP=0 通告。现任 PE2 继续以 DP=1 通告；同值比较时，DP 先破平局，于是 PE2 留任。

这意味着“配置偏好”和“对外在用偏好”可能故意不同。前者保留长期意图，后者保留当前任期。如果监控系统只保留一种值，就会把规范状态误报成漂移，或者反过来忘掉未来要恢复的顺序。

非回切也不是免费安全。它减少一次恢复时的切换，却可能长期保留已经不再是容量、位置或策略首选的 DF。参考 PE 后续失败、相关路由撤回、管理员再次改值，都会触发新的选择；返回 PE 若通告了冲突算法，Don't Preempt 也挡不住全体回退默认选举。

配置权限决定了流量责任

RFC 9785 的安全讨论指出，基于偏好的算法让配置直接控制某个 Ethernet Tag 的 DF。取得配置权限的攻击者可以改 Preference，从而改变流量经过的 PE；还可以制造算法冲突，迫使回退并削弱非回切。

按 Ethernet Tag 范围覆盖 Highest/Lowest 的本地规则同样要求所有 PE 一致。若视图不一致，规范明确警告可能丢包或重复。因而一次可审计变更至少要保留：操作者身份、行政值、在用通告值、DP、算法集合、候选资格、每个 Tag 的获胜者、数据面表项和真实流量。

RFC 9784 说明这些算法也适用于虚拟 Ethernet Segment；它所处理的单个 EVC 与物理 ENNI 故障范围、vESI 和 grouping withdrawal 属于另一篇机制。本文也不讨论冗余组播源，只回答偏好选举的证据边界。

RFC Editor 记录、IETF Datatracker 与核对时未列出匹配项的勘误查询，能证明规范及其登记状态；它们不能证明部署率或生产表现。