摘要

  • MEF 的以太网树服务为每条接入电路指定根或叶角色。根可以与其他根和叶通信；叶只能与根通信，叶之间不能直通。普通 VPLS 却把接入电路视为同等端点。
  • RFC 7152 用一个明确标注为假设的双边缘设备场景解释：目的 MAC 和帧送达都不够，远端边缘设备不知道帧从哪种角色的接入电路发出。
  • 这份 2014 年备忘录提出的是功能需求，包括多根、同一设备上的混合角色和向后兼容；后续 RFC 才描述框架与机制。标准记录不能证明实际部署或服务结果。

分析

角色附着在接入电路上

以太网树是一种带根的多点服务。根接入电路可以与根和叶通信；叶可以到达根，但流量不能从一个叶发往另一个叶。以太网 LAN 服务则允许各接入端彼此通信，二者的转发关系并不相同。

当服务经过运营商网络时，这个差别就变成了实际问题。RFC 7152 的例子中，两台运营商边缘设备分别连接一条根电路和一条叶电路，并通过伪线交换以太网帧。第二台设备收到帧后，能判断它来自另一台边缘设备，却未必知道帧最初进入第一台设备时走的是哪条本地电路，也不知道那条电路是否属于叶。

目的 MAC 已知也不能消除这个缺口。目的地址说明帧要去哪里，却不携带入口接入电路被赋予的服务角色。远端设备缺少该角色，就无法可靠地对已知单播、未知单播、广播和组播应用叶间限制。RFC 特别说明，这个拓扑只是用于阐明问题的假设，并不代表典型部署。

VPLS 传递了连通性，却没有传递这项策略

当时的 VPLS 模型将接入电路一视同仁，在同一实例中提供任意端点之间的连通性。它适合模拟以太网 LAN，却没有表达 MEF 以太网树要求的根叶关系。缺失的不是另一条客户地址，而是接入电路的服务属性；帧穿过运营商核心后，这项属性仍必须能被解释。

因此，RFC 7152 列出的是需求，而非宣布一套已完成的解决方案。方案必须禁止叶与叶通信，支持多个根，并允许根和叶电路同时接在一台边缘设备上。它还要求明确适用的二层 VPN 技术，并尽量减少对既有 VPLS 和 EVPN 部署的影响。如果只有部分边缘设备具备新能力，限制只在合规设备范围内成立；这并不等于整个路径都能端到端隔离。

备忘录列举了可能的场景：中心辐射型 VPN、批发接入、移动回传、时钟同步、互联网接入、广播视频和设备管理。这些是需求文档中的用例，不是已部署以太网树服务的统计。文档还把 E-Tree 与 IETF 当时讨论的虚拟专用组播服务区分开：E-Tree 可承载遵循根叶规则的单播与组播流量，单纯的组播服务并不能覆盖所有 E-Tree 流量模式。

后续标准把缺失的上下文说清楚

同年稍后发布的 RFC 7387 提出了以太网树架构框架，并点明两项缺口：现有二层 VPN 不区分接入电路角色，远端设备也收不到帧来自根还是叶的标记。RFC 7796 后来规定了 VPLS 中的 E-Tree 支持：用不同 VLAN 标识根源帧与叶源帧，让设备能在叶端口过滤流量。RFC 8317 又将 E-Tree 支持扩展到 EVPN 和 PBB-EVPN。

这条标准化脉络展示了服务规则如何变成工程需求，再发展为协议机制。它不能说明这些机制的采用范围，不能证明特定运营商已配置它们，也不能证明客户流量在实际网络中得到了隔离。RFC 7152 是信息类需求文件，不是故障报告、部署调查或互联网标准。

历史意义也不应夸大成“帧失去了来源”。帧仍保留自己的地址，也通过某种传输到达。可能在层间边界丢失的，是运营商对服务接入电路的认知；正是这项属性决定了帧应以何种角色转发。网络可以送达比特，却没有足够上下文兑现服务约定。

来源

RFC Editor 的 RFC 7152 信息页记录了该文档的发布状态。

主要依据是 RFC 7152，其中定义了需求，并说明双边缘设备例子是假设场景。RFC 7387、RFC 7796 与 RFC 8317 记录了后续框架以及 VPLS、EVPN 机制。这些资料能证明文档规定了什么，却没有给出采用率、运营商配置、流量测量或某个具体运营结果的证据。