摘要

  • RFC 3318 允许安装类策略使用 * 开头的角色组合，让一条规则匹配具备必需角色、同时还带有任意额外角色的多个接口。
  • 这种压缩没有自动产生优先级：多条命中策略发生冲突时，应由 PDP 先裁决；若冲突仍被下发，PEP 必须拒绝，而不能在设备里临时拼出自己的政策。

网络策略系统里最容易看见的问题是重复。十个接口需要相同处理，人们自然不愿写十份几乎一样的配置。最难看见的问题却是重叠：一条简洁规则覆盖的对象越多，它与另一条规则相遇的机会也越多。2003 年的 RFC 3318 同时记录了这两面。

它定义的是 COPS-PR 体系里的 Framework Policy Information Base。Policy Decision Point（PDP）负责作出供应决策，Policy Enforcement Point（PEP）代表接受并执行策略的设备，SPPI 则提供供应类与供应实例的建模语言。Framework PIB 为不同主题的客户端补上共同词汇，包括角色、能力集、状态版本、限制和错误。

角色首先是一串与接口关联的字符。它可以表示 finance、manager、骨干接口、防火墙或其他功能。一个接口可以同时拥有多个角色。策略实例带有 RoleCombination，系统用这个集合判断策略是否适用于接口。这样，中央策略不必知道某台设备把端口叫作哪个本地 IfIndex，也不必为具有相同功能的多个接口重复下发一份策略。

这不是任意标签。比较区分大小写，角色组合必须按 US-ASCII 字典序排列。a+b 是集合的合法格式；b+a 不是另一个组合，而是同一集合的非法写法。没有角色的接口使用 null 组合。规范要求统一序列化，是为了让两端比较集合时不必猜测顺序。

随后，星号进入模型。在 install 或 install-notify 类中，策略可以使用 *+a+b。它表示接口必须包含 a 与 b，但还可以包含零个或多个其他角色。星号不能作为接口真实上报的角色，也不能嵌在角色名称中做字符匹配；它表达的是集合包含关系。RFC 3318 明确举例：*+b+e+g 可以命中 a+b+c+e+f+g。

这种表达能够大幅减少重复。假设三个接口都带有 A、B，但分别还有 R1、R2、R3，一条 *+A+B 就能覆盖三者。PDP 不必把同样的处理复制三遍，运营者也可以直接表达“凡是同时具有 A 与 B 的接口”。

但集合包含没有回答谁优先。RFC 3318 承认，一个接口可能因为多个通配角色组合而命中多条策略。多重命中未必冲突：两条规则可能作用于不同字段，也可能完全兼容。可是，如果它们试图给同一控制面指定互不相容的结果，星号本身没有排序能力。

规范把责任留给 PDP。控制器应该在发送前尝试解决冲突。如果由于 PDP 错误，或者由于某台设备独有的限制，两条冲突策略仍被一起送到 PEP，设备必须拒绝安装并返回错误。这里的拒绝不是自动化失败，而是防止执行层偷偷变成决策层。

RFC 里的 finance 与 manager 例子更清楚。起初，两个接口带有 finance，另一个接口带有 manager。当一位财务人员升任经理，第二个接口就出现新组合 finance+manager。PDP 可以规定 manager 政策优先，也可以为财务经理生成第三条政策，例如使用不同 DSCP。无论结果是否与旧政策之一相同，PDP 都要为新组合给出明确答案。

PEP 不能把 finance 与 manager 两份旧策略自行拼接。它离报文最近，看似最了解本地情况，但一旦允许本地合成，不同厂商可能给同一组角色算出不同结果。中央控制器也无法再解释设备上的最终处理究竟获得了哪条政策授权。显式拒绝留下可调查的失败；静默合并只留下看似成功的漂移。

角色变化也不是一个瞬时事实。PEP 在完整请求状态中报告接口、角色组合与能力集。PDP 可以通过非请求决策改变接口关联。PEP 处理成功后，先发成功报告，再为所有开放上下文提交更新的完整状态；处理失败时则只发失败报告。PDP 在成功到来前不应假定新状态，而在后续请求和决策完成前，系统还可能收到基于旧角色的政策。

因此，“接口已经被标成 manager”不等于“所有相关策略已经重新计算并生效”。角色意图、设备接受、状态刷新、PDP 新决策、PEP 回执和数据平面执行是不同凭据。RFC 3084 给出了 COPS-PR 的请求—决策—报告框架，RFC 3159 定义 PIB、PRC 与 PRI 的模型；RFC 3318 则把角色碰撞放进这条状态链。

加密与认证也不能替代裁决。RFC 3318 警告，可配置内容一旦被误配置，后果可能严重，并指向 PDP 与 PEP 之间的传输保护。保护能够确认消息来源、防止途中篡改，却不能告诉系统 finance 与 manager 谁应优先，也不能判断二者在某种硬件上是否兼容。

这套体系后来没有成为长期主线。2016 年，IESG 将 RFC 3318、COPS-PR 与 SPPI 转为 Historic，理由包括部署有限，以及 IETF 的配置管理工作转向 NETCONF 与 YANG。这限制了我们对实际采用情况的推断，却没有取消通配规则的责任问题。

RFC 3318 留下的价值不在星号的语法，而在它拒绝把“少写几条规则”误当成“少做几次决定”。通配符可以压缩表达，不能凭空生成优先级。控制器必须说明重叠如何解决，设备在答案不完整时必须拒绝。只有保存这条边界，策略系统才能证明最终结果是中央选择，而不是执行端的偶然拼接。

来源：RFC 3318、RFC 3084、RFC 3159，以及 IESG 2016 年状态变更。