Zusammenfassung

  • MVPN- und EVPN-Auto-Discovery-Routen verändern nach RFC 10018 die Leaf-Menge einer SR-P2MP-Policy; erst ein Controller berechnet und instanziiert daraus einen Baum.
  • Ein Liefernachweis muss Policy-Generation, Replikationszustand, Tree-SID, Dienstkontext, Split Horizon und die Beobachtung am Empfänger über gemeinsame Identitäten verbinden.
  • Hooman Bidgoli gehört zu den fünf genannten Autoren des RFC. Die Quellen belegen einen Beitrag zu gemeinschaftlicher Standardisierung, keine alleinige Erfindung oder Kontrolle eines Produktivnetzes.

Bei einem Change Review steht häufig zuerst die Topologie im Mittelpunkt. Der Eintrittsrouter zeigt die erwartete Zahl von Leaves, der Controller hat eine Anfrage angenommen, und auf der Übersichtsseite erscheint ein grüner Baum. Für eine Abnahme wirkt das wie eine geschlossene Beweiskette.

Tatsächlich stammen die drei Aussagen aus unterschiedlichen Zeitpunkten und Systemen. Eine Auto-Discovery-Route hat Mitgliedschaft angekündigt. Ein Controller kann einen Rechenauftrag angenommen haben, ohne dass dieselbe Generation überall aktiv ist. Selbst ein installierter Tree-SID sagt noch nicht, ob der Dienstkontext stimmt oder der Endpunkt den Stream verarbeitet.

RFC 10018 erschien im August 2026 im Standards Track der IETF. Rishabh Parekh und Daniel Voyer sind die Herausgeber; Clarence Filsfils, Hooman Bidgoli und Zhaohui Zhang sind die weiteren Autoren. Das Dokument verbindet MVPN und EVPN mit Segment-Routing-P2MP-Bäumen und Ingress Replication. Seine Struktur liefert keinen universellen Erfolgsstatus, sondern eine Folge prüfbarer Übergaben.

Auto-Discovery beschreibt beabsichtigte Mitgliedschaft

Eine SR P2MP Policy besitzt eine Root, eine Leaf-Menge und mindestens einen candidate path. Ein Kandidat kann Constraints oder ein Optimierungsziel enthalten und null oder mehrere P2MP tree instances haben. Gewünschte Teilnehmer, ausgewählte Policy und instanziierter Baum sind folglich getrennte Zustände.

Importiert ein Ingress PE die Auto-Discovery-Route eines Egress PE, erkennt es diesen als Leaf des betroffenen P-Tunnels und fügt ihn der Policy hinzu. Ein Route Withdrawal entfernt ihn. Auf der Ausgangsseite wird die Route dem passenden MVPN- oder EVPN-Kontext zugeordnet; das Policy-Modul erfährt, dass der PE als Leaf oder Bud beitritt.

Das ist ein bedeutender Fortschritt gegenüber einer ausschließlich manuellen Empfängerliste. Route Origin, Importzeitpunkt, Policy-Zuordnung und Withdrawal können untersucht werden. Fehlt die Route, erklärt das, warum ein Ziel nie in die geplante Verteilung gelangte.

Die Route beobachtet jedoch kein Nutzpaket. Sie kennt weder die Lösbarkeit der Constraints noch den Zustand aller Replikationsknoten oder des Empfängerprozesses. Auto-Discovery übergibt einen Auftrag an die nächste Ebene. Sie bestätigt nicht dessen Ausführung.

Der Controller benötigt eine prüfbare Generation

Aus Leaf-Menge, candidate path, Constraints und Ziel berechnet ein Controller eine P2MP tree instance. Er verbindet replication segments an Root, Zwischenknoten und Leaves. Ob diese Segmente über BGP, PCEP, NETCONF oder einen anderen Mechanismus installiert werden, liegt außerhalb des RFC-Umfangs.

Für den Betrieb ist gerade diese Grenze wichtig. Die neue Menge kann am Router vorliegen, während die Berechnung wartet. Eine Nebenbedingung kann unmöglich sein. Eine southbound Transaktion kann fast alle Geräte erreichen und eines auf der alten Version zurücklassen. Eine erfolgreiche Antwort kann der Aktivierung im forwarding hardware vorausgehen.

Ein belastbarer Datensatz benennt deshalb die Generation. Candidate-path-ID, Hash der Leaf-Menge, Constraints, Optimierungsziel, Controller Request, berechnete PTI-Identität und Acknowledgement jedes Knotens müssen dieselbe Generation referenzieren. Ein isoliertes „success“ ist nicht mit der Datenebene verknüpfbar.

Die Nachbardokumente spiegeln diese Trennung. RFC 9960 definiert die Policy, RFC 9524 die Rollen Root, Bud, Leaf und intermediate replication node, RFC 9961 Ping und Traceroute für MPLS-SR-P2MP-Policies. Policy, programmierter Zustand und OAM sind drei komplementäre Belege.

Der Tree-SID ersetzt den Dienstschlüssel nicht

Eine instanziierte Baumstruktur hat einen Tree-SID. Die Root legt den Payload in den Baum; Providerknoten replizieren entlang der installierten Zweige; am Leaf wird der Tree-SID entfernt und der Payload einem MVPN- oder EVPN-Kontext zugeführt.

Bei einem dedizierten Baum kann die Baumidentität zur Ermittlung des Dienstes genügen. Ein Shared Tree transportiert hingegen mehrere VPNs im selben P-Tunnel. Ein zusätzliches Service Label, ein SRv6 Service SID oder Argument muss den Kundenkontext unterscheiden. Das Paket kann den richtigen Baum durchlaufen und dennoch in der falschen Tabelle landen.

EVPN Multihoming benötigt außerdem Split Horizon. Die Filterung verhindert, dass BUM-Traffic über dasselbe Ethernet Segment zurückkehrt oder doppelt eintrifft. Eine richtige Leaf-Menge beweist nicht die richtige ESI-Behandlung. Ein Empfänger mit zwei Kopien hat einen Fehler erlebt, auch wenn das Mitgliedschaftsdiagramm stimmt.

Der Nachweis muss daher Tree-SID, Service Label oder SID, Ethernet-Segment-Kontext, Split-Horizon-Wert, Ingress PE und Egress Lookup verbinden. Diese Werte aus der Anzahl der Leaves abzuleiten, wäre eine unbelegte Annahme.

Ingress Replication hat eine andere Fehlerfläche

RFC 10018 behandelt ebenso Ingress Replication. Dabei erzeugt das Ingress PE einzelne Kopien und sendet sie über SR-MPLS- oder SRv6-Pfade an die Egress PEs. Das SR-P2MP-Policy-Modul und sein Controller greifen nicht in derselben Weise ein wie bei einem gemeinsamen Baum.

Für den Kunden können beide Varianten ähnlich wirken. Ein P2MP-Baum hängt jedoch von gemeinsamer Generation und Zwischenreplikation ab. Ingress Replication hängt stärker von der Kopienzahl an der Quelle und der Unicast-Erreichbarkeit jedes Ausgangs ab. Ein einziges Feld „Multicast aktiv“ beseitigt die für die Diagnose notwendige Unterscheidung.

In einer Migration sollte pro Empfänger dokumentiert sein, welcher Modus gilt, wer den Cutover verantwortet und welcher Messwert den alten Zustand schließt. Andernfalls kann ein alter Zweig neben einer neuen Kopie fortbestehen oder beide Teams können die Entfernung dem jeweils anderen zuschreiben.

Erst der Empfänger schließt die Beweiskette

An der Root werden angenommene Kundenpakete und die in den konkreten Tree-SID oder Replication Set eingespeisten Pakete gezählt. Jeder Replikationsknoten meldet Input, replizierte Outputs und Drops für dieselbe Generation. Das Leaf erfasst Decapsulation und Service Lookup. Die Empfängergrenze misst erwartete Sequenz, Verlust, Duplikate, Reihenfolge, Latenz und tatsächlichen Verbrauch.

Diese Messungen dürfen nicht in einem Ampelwert verschwinden. Der Root Counter bestätigt die Annahme. Zweigzähler lokalisieren einen Verlust. Decapsulation zeigt die Ankunft am Egress Router. Nur die letzte Beobachtung beantwortet, ob das beabsichtigte Ziel den Dienst unter den vereinbarten Bedingungen erhielt.

Auch negative Übergänge gehören in den Test. Ein Leaf Withdrawal unter Last zeigt die Zeiten für Route, Neuberechnung, Deprogrammierung und tatsächliches Ende der Kopien. Ein späterer Rejoin muss als neue Generation verfolgbar sein. Der simulierte Installationsfehler eines Zwischenknotens darf keine Vollständigkeitsanzeige übrig lassen. Beim Multihoming-Failover müssen Duplikate ebenso gemessen werden wie Verlust.

Was die Quellen über Hooman Bidgoli belegen

Das am 1. September 2026 erfasste IETF-Datatracker-Profil nennt sieben RFCs für Hooman Bidgoli. Darunter befinden sich RFC 9524 zur SR-Replikation, RFC 9960 zur P2MP Policy, RFC 9961 zu P2MP OAM und RFC 10018. Letzterer nennt seine Zugehörigkeit zu Nokia in Ottawa. Eine offizielle Nokia-SReXperts-Seite beschrieb zum Erfassungszeitpunkt Arbeit an IP/MPLS, Multicast und Router Security.

Diese Abfolge macht seine Relevanz für mehrere Systemgrenzen nachvollziehbar. Sie belegt weder Alleinautorschaft noch Kontrolle über den IETF-Konsens oder die Ergebnisse einer bestimmten Implementierung. RFC 10018 nennt fünf Autoren und baut auf früheren MVPN-, EVPN- und Segment-Routing-Standards auf.

Eine personenzentrierte Analyse ist dann nützlich, wenn sie kollektive Verantwortung sichtbar macht, statt sie zu personalisieren. Bidgolis dokumentierte Mitarbeit lenkt den Blick auf eine präzise Grenze: Mitgliedschaft kann eine Baumänderung auslösen, doch Existenz, Dienstkontext und Empfang bleiben getrennte Behauptungen.

Den Multicast-Nachweis als Join entwerfen

Für jeden Change gehören Dienst, Tenant, Übertragungsmodus, Root, importierte Auto-Discovery-Routen, Leaf- oder Bud-Mitgliedschaft, candidate path, Constraints und Ziel in den Datensatz. Danach folgen Controller Request, PTI-Generation und die Bestätigung der replication segments je Gerät.

Tree-SID wird mit Service Label oder SID, Ethernet Segment, Split Horizon und Egress Lookup verbunden. Den Abschluss bilden angenommene Pakete, erzeugte Kopien, Branch Drops, Leaf Decapsulation, OAM, Empfängerresultate und Alarmzeitpunkte. Für ein Withdrawal sind Initiator, Bereinigungszeiten und der Nachweis des Traffic-Endes festzuhalten.

Eine solche Kette macht Multicast nicht trivial. Sie macht eine Abweichung auffindbar. Die Leaf-Menge bleibt eine genaue Aussage über beabsichtigte Mitgliedschaft. Auslieferung bleibt eine andere Aussage, die erst durch die nachfolgenden Belege gültig wird.

Quellen