Zusammenfassung

  • RFC 9960 identifiziert eine SR P2MP Policy durch Root und Tree-ID und unterscheidet Leaves, Candidate Paths und PTIs. Diese Bezeichner beschreiben Forwarding, nicht das Recht eines Kunden oder einer Institution auf Empfang.
  • RFC 9961 kann eine bestimmte PTI innerhalb eines Candidate Path adressieren. Der Text stellt klar, dass damit nicht der Candidate Path als Ganzes getestet wird und SRv6 nicht zum Anwendungsbereich gehört.
  • Ein Multipoint-Audience-Receipt sollte Mitgliedschaftsentscheidung, Policy, Candidate Path, PTI, Leaf-Menge, Controller-Generation, OAM-Scope und Abschluss des Wechsels verbinden. Das ist Daniel Kades Vorschlag, keine IETF-Vorgabe.

Der Baum kennt die Abzweigung, nicht den Vertrag

Point-to-Multipoint spart unnötige Kopien. Vom Root läuft ein Datenstrom über gemeinsame Verbindungen; erst an Verzweigungen entstehen mehrere Ausgaben. RFC 9960 gibt dieser Struktur für SR-MPLS und SRv6 eine standardisierte Architektur.

Eine Policy trägt die Identität <Root, Tree-ID>. Sie enthält Leaves sowie einen oder mehrere Candidate Paths mit Randbedingungen und Optimierungszielen. Der Controller berechnet daraus P2MP Tree Instances und installiert Replication Segments auf Root, Zwischen- und Leaf-Knoten.

Die genaue Benennung erlaubt Fehlerdiagnose und kontrollierten Wechsel. Sie sagt aber nichts über die Mitgliedschaft im Dienst. Ein Leaf ist ein Forwarding-Endpunkt oder als Bud zugleich Endpunkt und weitere Verzweigung. Hinter der Adresse kann ein aktiver Kunde, ein abgelaufener Tenant, ein temporärer Standort oder ein neuer Adressinhaber stehen.

Die Berechtigung entsteht außerhalb des Routing-Systems: in einem Vertrag, Rollenregister, Tenant-Control-Plane, Einsatzplan oder einer verantwortlichen Entscheidung. Automatisierung übersetzt diese Population in Adressen und Service Contexts. Ist die Übersetzung veraltet, liefert der Baum die veraltete Entscheidung besonders zuverlässig aus.

Dass der RFC diese lokale Autorität nicht definiert, ist kein Mangel. Ein Internetstandard soll Mechanismen interoperabel machen, ohne Mitgliedschaftsordnungen aller Betreiber vorwegzunehmen.

Eine Tree-ID kann mehrere Betriebszustände verdecken

Eine Policy kann mehrere Candidate Paths besitzen. Der Root wählt den aktiven nach den Regeln aus RFC 9256. Ein Candidate Path kann ohne PTI bleiben, wenn seine Anforderungen nicht erfüllbar sind. Beim Make-Before-Break können dagegen vorübergehend mehrere PTIs existieren.

Aktiv darf nur eine PTI sein. RFC 9960 warnt, dass mehrere aktive PTIs des aktiven Candidate Path doppelte Pakete an Leaves liefern können. Der Instance-ID kommt deshalb eigene Beweisbedeutung zu. Alter und neuer Baum teilen die Policy, nicht aber zwingend Topologie und Replikationszustand.

Der Controller kann die neue PTI zuerst aufbauen, dann aktivieren und danach die alte entfernen. Diese Reihenfolge reduziert Verlust, erzeugt jedoch ein Intervall mit doppeltem Zustand. Eine Anzeige auf Tree-ID-Ebene verschweigt, welche Instanz getestet wurde und wann die alte tatsächlich aufhörte.

Auch Transport und Dienst können auseinanderfallen. Üblicherweise gehört eine PTI zu einem Multipoint-Dienst, doch mehrere Dienste dürfen denselben Baum nutzen, wenn der Service Context sie an Root und Leaves trennt. Ein gesunder Baum ist deshalb noch kein Beweis für den richtigen Dienst am richtigen Empfänger.

Der Controller übt delegierte Macht aus

Root, Leaf-Menge und Candidate Paths können durch Menschen, Netzwerkknoten oder Maschinen provisioniert werden. Der Controller berechnet, vergibt Replication-SIDs und installiert per PCEP, BGP, NETCONF/YANG oder anderen Verfahren. Eine explizite statische Topologie ist ebenfalls möglich.

Damit besitzt der Controller reale operative Macht. Er kann Verteilung erweitern, einen Wechsel vorbereiten und fehlgeschlagene Installation wiederholen. Daraus folgt nicht, dass er die Mitgliedschaftsentscheidung besitzt. Oft verarbeitet er lediglich die Netzwerkprojektion eines vorgelagerten Systems.

Heng Lus Policy Mirror erklärt, warum beides aufgezeichnet werden muss. Laufende Infrastruktur zeigt, wer tatsächlich handeln kann. Sie bestätigt aber nicht aus sich selbst, dass der Handelnde institutionell autorisiert war. Ein akzeptierter API-Aufruf ist eine Ausführungsspur, kein Mandat.

Auch Fehlergenerationen dürfen nicht überschrieben werden. Ein SID-Konflikt kann die Installation eines Replication Segment verhindern. Der RFC empfiehlt begrenzte Wiederholungen und Alarmierung und erwägt den Abbau einer teilweisen PTI. Nur wenn Versuch, Fehlergrund, Bereinigung und Nachfolger getrennte Identitäten behalten, ist die Übergangsrealität rekonstruierbar.

RFC 9961 liefert einen engen, starken Befund

RFC 9961 erweitert Ping und Traceroute für MPLS SR P2MP Policies. Die Anfrage nennt Candidate Path und PTI; Root, Tree-ID und Instance-ID adressieren die konkrete Instanz. Das ist deutlich belastbarer als „Multicast ist verfügbar“.

Der Scope bleibt bewusst begrenzt. Das neue Sub-TLV testet eine PTI innerhalb eines Candidate Path, nicht den Candidate Path als abstraktes Ganzes. Das Verfahren gilt für MPLS Replication-SIDs und nicht für SRv6. Außerdem kann der Kreis der Antworten begrenzt werden.

Ein Erfolg belegt eine zeitgebundene Beobachtung des benannten MPLS-Datenpfads. Er belegt weder nutzbare Applikationszustellung noch aktuelle Mitgliedschaft, korrekte Controller-Eingabe, Duplikatfreiheit während des Wechsels oder das Verhalten einer SRv6-Variante.

Diese Ehrlichkeit macht OAM wertvoll. Ein sauber abgegrenzter Befund lässt sich mit Autoritäts-, Konfigurations- und Änderungsdaten verbinden. Ein universelles Grünsignal verwischt diese Verbindungen.

Inhalt des Audience-Receipts

Der Datensatz beginnt beim Dienst: Service- und Context-ID, autoritative Mitgliederquelle, Version, Gültigkeit, Genehmiger und Ausschlüsse. Danach folgt die Zuordnung stabiler lokaler Subjekte zu Leaf- oder Bud-Adressen samt Hinzufügung, Entfernung und Ablauf. Eine wiedervergebene Adresse darf die alte Berechtigung nicht erben.

Es folgen <Root, Tree-ID>, Origin-Tupel des Candidate Path, Randbedingungen, Ziel und Auswahlgrund. Die Instanzsektion enthält alte und neue Instance-ID, exakte Leaves/Buds, Controller- und Konfigurationsgeneration, SID-Zuteilung und Installationsergebnis pro Knoten.

Die Beobachtung nennt OAM-Verfahren, den MPLS-Scope von RFC 9961, Ziel-PTI, erwartete Antworten, Zeitpunkt und Ergebnis. Die Transition nennt Aktivierungsreihenfolge, Koexistenzdauer, Duplikatbeobachtung, Rollback-Trigger und Beleg der Entfernung der alten PTI.

Zum Abschluss werden aktive und Backup-Instanzen mit der aktuellen Population abgeglichen. Der Receipt erhält Ablaufdatum und Negativumfang. Hashes zeigen nachträgliche Ersetzungen, beweisen aber weder legitime Quelle noch ehrlichen Sensor. Sensible Empfängerlisten können geschützt bleiben; öffentlich reichen gegebenenfalls Zahlen, Zeitpunkte und Ausnahmen.

Der Begriff ist ein redaktioneller Vorschlag. Weder RFC 9960 noch RFC 9961 definiert einen solchen Compliance-Nachweis.

Entfernung ist ein positiver Kontrollschritt

Hinzufügungen hinterlassen viele Erfolge. Entfernung wird häufig nur als Abwesenheit betrachtet. Bei P2MP muss sie aktive, vorbereitete, Backup- und teilweise installierte Generationen erreichen.

Der Abschluss sollte getrennt beweisen, dass der Root keinen Traffic mehr in die alte PTI steuert, ihre Replikationszustände entfernt wurden und ausgeschlossene Leaves nicht in Backups verbleiben. Inaktiv ist nicht dasselbe wie gelöscht.

RFC 9960 warnt außerdem vor externer Paket-Injektion bei unzureichend geschützter SR-Domain sowie vor Controller-fehlerhaften Schleifen, die bis zum Ablauf von TTL oder Hop Limit einen Sturm erzeugen können. Ein grüner Leaf-Test prüft diese Bedingungen nicht automatisch.

Grenzen und Quellen

Die Quellen belegen keine Implementierung eines benannten Betreibers, keinen unberechtigten Empfänger, keine reale Duplikation, keinen Angriff und keinen Performancegewinn. Sie belegen Architektur und ausgewiesene Risiken. Lokale Umgebungen können MPLS, SRv6, statische Bäume, andere OAM-Verfahren oder gar kein P2MP wählen.

Die belastbare Aussage bleibt eng: Tree-ID identifiziert die Transport-Policy, Instance-ID ihre Realisierung, RFC 9961 beobachtet eine MPLS-PTI. Die Empfangsberechtigung stammt aus einer anderen Autorität und muss neben dem ausführenden Baum erhalten bleiben.