Zusammenfassung

  • Beim MEF-Dienst Ethernet Tree erhält jeder Attachment Circuit die Rolle Root oder Leaf. Ein Leaf kann mit Roots, aber nicht mit anderen Leafs kommunizieren; gewöhnliches VPLS behandelt alle Anschlüsse gleich.
  • Das ausdrücklich hypothetische Zwei-PE-Beispiel in RFC 7152 zeigt, warum Ziel-MAC und zugestellter Frame nicht genügen: Das entfernte PE kennt die Rolle des Quellanschlusses nicht.
  • Das Memorandum von 2014 formuliert Anforderungen wie mehrere Roots, gemischte Rollen an einem PE und Rückwärtskompatibilität. Spätere RFCs beschreiben Rahmen und Mechanismen, belegen aber weder Einsatz noch Dienstergebnis.

Analyse

Die Rolle gehörte zum Anschluss

Ethernet Tree ist ein verwurzelter Mehrpunktdienst. Ein Root-Anschluss kann mit Roots und Leafs kommunizieren. Ein Leaf darf Roots erreichen, aber der Verkehr soll nicht von einem Leaf zu einem anderen laufen. Ethernet LAN folgt einer anderen Regel: Dort können die Anschlüsse untereinander kommunizieren.

Sobald der Dienst durch das Netz eines Anbieters führt, wird dieser Unterschied praktisch. Im Beispiel von RFC 7152 verbinden zwei Provider Edges jeweils einen Root- und einen Leaf-Kundenanschluss und tauschen Ethernet-Frames über ein Pseudowire aus. Das empfangende PE erkennt den entfernten PE als Quelle. Es erkennt jedoch nicht zwingend, an welchem lokalen AC der Frame beim ersten PE einging oder ob dieser AC ein Leaf war.

Auch eine bekannte Ziel-MAC löst das Problem nicht. Die Adresse zeigt, wohin der Frame soll, nicht welche Servicerolle seinem Eingangsanschluss zugewiesen wurde. Ohne diese Information kann das entfernte PE die Leaf-zu-Leaf-Sperre für bekannte und unbekannte Unicasts, Broadcasts und Multicasts nicht zuverlässig anwenden. Die RFC kennzeichnet die Skizze ausdrücklich als hypothetisch und nicht als typischen Dienst.

VPLS transportierte Konnektivität, aber nicht diese Richtlinie

Das damalige VPLS-Modell behandelte alle Attachment Circuits gleich und ermöglichte innerhalb einer Instanz Verbindung zwischen allen Anschlüssen. Das eignete sich zur Emulation eines Ethernet LAN, drückte aber die Root-Leaf-Beziehung des MEF-Dienstes nicht aus. Es fehlte nicht bloß eine weitere Kundenadresse, sondern eine Eigenschaft des Dienstanschlusses, die auch nach der Überquerung des Provider-Kerns auswertbar bleiben musste.

RFC 7152 stellte deshalb Anforderungen auf, statt eine fertige Lösung auszurufen. Eine Lösung musste Leaf-zu-Leaf-Verkehr verhindern, mehrere Roots zulassen und Root- und Leaf-ACs am selben PE erlauben. Sie sollte außerdem die anwendbare Layer-2-VPN-Technik benennen und bestehende VPLS- und EVPN-Dienste möglichst wenig beeinträchtigen. Unterstützten nur manche PEs das neue Verhalten, galt die Einschränkung nur im kompatiblen Bereich; eine durchgehende Isolation über einen nicht unterstützten Abschnitt versprach der Text nicht.

Als mögliche Einsatzfelder nennt das Memorandum Hub-and-Spoke-VPNs, Wholesale-Zugang, Mobilfunk-Backhaul, Zeitsynchronisierung, Internetzugang, Video und Geräteverwaltung. Das sind Anwendungsfälle in einem Anforderungsdokument, keine Statistik tatsächlich betriebener E-Tree-Dienste. RFC 7152 grenzt E-Tree auch vom damals diskutierten Virtual Private Multicast Service ab: E-Tree erlaubt Unicast und Multicast unter Root-Leaf-Regeln; ein reiner Multicastdienst ersetzt nicht alle E-Tree-Verkehrsarten.

Spätere RFCs machten den fehlenden Kontext ausdrücklich

RFC 7387 legte noch 2014 ein E-Tree-Architekturmodell vor und benannte zwei Lücken: Layer-2-VPNs unterschieden die Rollen der Attachment Circuits nicht, und ein entferntes PE erhielt keine Anzeige, ob ein Frame von Root oder Leaf stammte. RFC 7796 spezifizierte später E-Tree-Unterstützung in VPLS mit getrennten VLAN-Kennungen für Root- und Leaf-Frames, damit Geräte an Leaf-Ports filtern können. RFC 8317 erweiterte die Unterstützung auf EVPN und PBB-EVPN.

Diese Abfolge zeigt, wie eine Dienstregel zur technischen Anforderung und später zu Protokollmechanismen wurde. Sie misst weder die Verbreitung noch belegt sie, dass ein bestimmter Anbieter die Mechanismen aktivierte oder Kundendaten tatsächlich isolierte. RFC 7152 ist ein Informational-Anforderungsdokument, kein Störungsbericht, keine Einsatzstudie und kein Internetstandard.

Die historische Aussage ist enger als „der Frame verliert seine Quelle“. Er behält seine Adressen und kommt über einen Transport an. An einer Schichtgrenze kann vielmehr das Wissen des Anbieters über den Dienstanschluss verschwinden, das dem Frame seine Weiterleitungsrolle gab. Ein Netz kann Bits zustellen und trotzdem den Kontext vermissen, der zur Einhaltung des Dienstvertrags nötig ist.

Quellen

Der RFC-Editor-Eintrag zu RFC 7152 bestätigt den Veröffentlichungsstatus.

Die Hauptquelle ist RFC 7152, die Anforderungen festlegt und ihr Zwei-PE-Beispiel als hypothetisch kennzeichnet. RFC 7387, RFC 7796 und RFC 8317 dokumentieren das Rahmenmodell sowie spätere VPLS- und EVPN-Mechanismen. Diese Quellen belegen die Spezifikationen, aber keine Verbreitungszahlen, Providerkonfigurationen, Verkehrsmessungen oder konkreten Betriebsergebnisse.