摘要

  • Stefan Wahl 表示，他讨论的 IXP 目录仍以单一 peering LAN 和“成员 ASN 接一个端口”的关系描述交换中心；同一地点如今可能承载多种服务。
  • 每项服务没有自己的身份，问题就不只是目录少了几栏：过滤规则、可接受前缀和信任来源也难以明确归属。

目录里的一座 IXP 只占一行，机房里的服务却有好几层。RIPE 92 上，Stefan Wahl 把这两幅图摆在一起：数据模型仍从单一 peering LAN 出发，实际运营已经加入远程 peering、云接入、托管缓存、多 ASN 以及跨越二层和三层的服务。

Route128 的 CTO、Euro-IX 董事会成员 Wahl 举了旧金山的例子。一个交换中心在二层 peering fabric 之外还运行三层服务；两个 VRF 让不同服务跨层连接，他用“Layer 2.5”概括这种结构。目录模型没有合适的位置描述这项服务。Wahl 还说，这不是纸面设想：相关服务已经承载流量。

当一个 IXP 有多项服务，“某成员接入该交换中心”就回答不了操作人员真正要问的事：哪项服务接受哪些前缀？它接在哪个 route server 或 POP？该服务采用哪些 IRR 来源或 RPKI 信任设置？如果目录没有给服务一个稳定身份，下游自动化只能猜测过滤规则该落在哪条边界上。

Wahl 提出的方向，是让服务有自己的描述和定位标识，并让目录与 API 能共享这套词汇。过滤和信任应沿着服务边界设置。他还列出 IPv6-only fabric、link-local 地址、以及按 VLAN 区分前缀上限等例子；这些内容都不容易塞进当前通用字段。

他的提议并不是合并目录、取代现有运营实践，也不是搭建实时验证器。配置状态和成员意图仍应留在运营工具中。留给工作组的问题更具体：给每项服务一个稳定的公开描述，还是让每个下游系统继续猜这一条记录指向哪层网络？RIPE 92 的逐字稿记录了提议和讨论，没有记录采纳决定或交付日期。

来源