Summary

  • MEF’s Ethernet Tree service assigned each attachment circuit a root or leaf role. A leaf could communicate with roots, but not with other leaves; ordinary VPLS forwarding treated attachment circuits as peers.
  • RFC 7152’s hypothetical two-edge example showed why destination MAC addresses and frame delivery were not enough: the remote provider edge did not know the role of the circuit where the frame had entered.
  • The 2014 memo specified functional requirements, including multiple roots, mixed roles at one edge and backward compatibility. Later RFCs defined frameworks and mechanisms, but the standards record does not prove deployment or service outcomes.

Analysis

The rule belonged to the attachment

An Ethernet Tree is a rooted multipoint service. A root attachment circuit can communicate with roots and leaves. A leaf can communicate with roots, but traffic must not pass from one leaf to another. That rule is different from an Ethernet LAN service, where all attachments can communicate with one another.

The distinction sounds simple until the service crosses a provider network. In RFC 7152’s example, two provider-edge routers each connect to one root and one leaf customer circuit. They exchange Ethernet frames over a pseudowire. When the second edge receives a frame from the first, it can see that the frame arrived from a remote provider edge. It cannot necessarily tell which local attachment circuit at the first edge supplied it, or whether that circuit was a leaf.

That uncertainty matters even when the destination MAC is known. The frame’s destination identifies where it is addressed; it does not carry the service role assigned to its ingress circuit. A remote edge that lacks the role cannot reliably apply a leaf-to-leaf restriction to unicast, unknown-unicast, broadcast and multicast traffic. The RFC calls its topology a hypothetical example, explicitly not a description of a typical service.

VPLS carried connectivity, not this policy

The existing VPLS model treated attachment circuits alike and provided any-to-any connectivity within an instance. That was useful for emulating an Ethernet LAN. It did not express the rooted forwarding relationship that MEF’s E-Tree service required. The missing information was not simply another customer address. It was a property of the service attachment that had to remain meaningful after frames crossed the provider core.

RFC 7152 therefore framed requirements rather than declaring a finished solution. A conforming approach had to prohibit communication between leaf attachments, allow multiple roots and permit root and leaf circuits to coexist on one provider edge. It also asked solutions to identify which Layer 2 VPN technology they applied to and to limit disruption to existing VPLS and EVPN deployments. Where only some provider edges supported the new behavior, the requirement was scoped to the compliant edges; that wording did not promise end-to-end isolation through an unsupported segment.

The memo listed possible settings such as hub-and-spoke VPNs, wholesale access, mobile backhaul, clock distribution, Internet access, broadcast video and device management. These are use cases in a requirements document, not a census of deployed E-Tree services. It also distinguished E-Tree from the IETF’s then-discussed Virtual Private Multicast Service: E-Tree permits both unicast and multicast patterns under root-and-leaf rules, while a multicast service is not a substitute for every E-Tree flow.

The standards trail made the missing context explicit

RFC 7387, published later in 2014, supplied an E-Tree architecture framework and named two gaps: existing Layer 2 VPNs did not distinguish attachment-circuit roles, and a remote edge did not receive an indication of whether a frame originated at a root or a leaf. RFC 7796 later specified E-Tree support in VPLS using separate VLAN identifiers to mark root-originated and leaf-originated frames, allowing forwarding equipment to filter frames at leaf ports. RFC 8317 extended E-Tree support to EVPN and PBB-EVPN.

This sequence shows how a service rule became an engineering requirement and then a set of protocol mechanisms. It does not establish how widely the mechanisms were implemented, whether a particular provider enforced them, or whether customer traffic was correctly isolated in practice. RFC 7152 is an Informational requirements record, not an incident report, a deployment study or an Internet Standard.

The historical lesson is narrower than “Ethernet frames lose their source.” They retain frame-level addresses and arrive through a transport. What may disappear at a layer boundary is the provider’s knowledge of the service attachment that gave those frames their forwarding role. A network can deliver the bits and still lack the context needed to honor the service contract.

Sources

The RFC Editor’s metadata record confirms the RFC’s publication status.

The primary record is RFC 7152, which defines the requirement set and marks its two-edge example as hypothetical. The later RFC 7387, RFC 7796 and RFC 8317 document a framework and subsequent VPLS and EVPN mechanisms. These sources establish what the documents specify; they do not supply adoption rates, provider configuration records, traffic measurements or proof of a named operational outcome.