Zusammenfassung

  • RFC 10018 kann einen SR-P2MP-P-Tunnel als <Root, Tree-ID> ankündigen und seine Blattmenge aus MVPN- oder EVPN-A-D-Routen ableiten. Das ist begrenzter Control-Plane-Nachweis, aber keine Bestätigung, dass derselbe PTI auf allen Knoten vollständig installiert ist oder jedes vorgesehene Blatt den richtigen Dienstinhalt erhält.
  • Freigabe und Abschluss müssen für dieselbe Candidate Path und dieselbe Instance-ID die Sollmenge, A-D-Mitgliedschaft, Controller-Annahme, Segmentinstallation, FIB, OAM-Antwort und Nutzdatenbestätigung je Blatt abgleichen. Der Rückbau verlangt spiegelbildliche Entfernungs- und Ruhebelege.

Ein Mehrpunktdienst scheitert anders

Die auffällige P2MP-Störung ist der Totalausfall. Die gefährlichere ist der beinahe vollständige Erfolg. Die Root sendet, Zwischenknoten replizieren, die meisten Blätter zählen Pakete. Durchsatz und Median bleiben plausibel. Nur ein Standort ist leer.

Ein Aggregat kann diesen Zustand korrekt messen und dennoch die falsche Entscheidung nahelegen. Elf funktionierende Blätter kompensieren das zwölfte nicht, wenn dieses Blatt eine vertraglich geschuldete Region, ein Sicherungsziel oder einen kritischen Verbraucher trägt.

RFC 10018 schafft für diese Architektur einen gemeinsamen Rahmen. MVPN und EVPN können P-Tunnel ankündigen, die durch SR-MPLS- oder SRv6-P2MP Tree Instances realisiert werden. BGP Auto-Discovery verbindet Dienstmitgliedschaft mit dem Leaf Set einer SR P2MP Policy. Ingress Replication über SR wird als eigener Modus beschrieben.

Die Spezifikation legt nicht fest, dass eine Meldung aus einer Schicht den Erfolg der nächsten bestätigt. Verfahren zwischen Policy-Modul und Controller werden ausdrücklich außerhalb des Umfangs belassen. Gerade dadurch wird sichtbar, wo ein Betreiber eigene Nachweise benötigt.

Policy-Identität und Bauminkarnation sind nicht dasselbe

Im PMSI Tunnel Attribute steht für den SR-P2MP-P-Tunnel das Tupel <Root, Tree-ID>. Der 32-Bit-Tree-ID ist an der Root eindeutig und wird vor deren IP-Adresse kodiert. IANA führt Tunneltyp 0x0C für SR-MPLS P2MP Tree und 0x0D für SRv6 P2MP Tree.

Das Tupel bezeichnet die Policy. RFC 9960 trennt davon Candidate Paths und P2MP Tree Instances. Eine Candidate kann ohne PTI bleiben, wenn kein Baum ihre Randbedingungen erfüllt. Bei Make-Before-Break können mehrere PTIs vorhanden sein; aktiv darf genau einer sein. Zwei aktive Instanzen der aktiven Candidate können Duplikate an die Blätter liefern.

Jeder PTI hat eine 16-Bit-Instance-ID. Die Replikationssegmente werden mit Root, Tree-ID, Instance-ID und Node-ID in Verbindung gebracht. Damit lässt sich eine langlebige Policy von jeder konkreten Topologie- und Forwarding-Inkarnation unterscheiden.

Fehlt die Instance-ID in Telemetrie und OAM, kann die alte Instanz die neue scheinbar bestätigen. Späte Acknowledgements lassen sich dem falschen Rollout zuordnen. Nach früher Wiederverwendung werden alte und aktuelle Zustände ununterscheidbar. Ein Name ist kein Versionsnachweis.

Die A-D-Route sagt „Mitglied“, nicht „zugestellt“

Bei MVPN fügt die Ingress-PE eine Egress-PE zum Leaf Set hinzu, wenn sie die einschlägige Intra-AS-I-PMSI- oder Leaf-A-D-Route importiert. Der Withdraw entfernt sie. Die Egress-PE tritt nach dem Root-Advertisement als Leaf oder Bud bei und erzeugt bei gesetztem Leaf-Information-Required-Flag eine Leaf-A-D.

EVPN verwendet entsprechend IMET, S-PMSI und Leaf A-D. Die Mitgliedschaft besitzt dadurch einen nachvollziehbaren Start und ein Ende. Das ist wesentlich stärker als eine anonyme Zieladresse in einer Controller-Datenbank.

Die Route programmiert aber nicht direkt den gesamten Baum. Das MVPN-/EVPN-Modul aktualisiert Candidate und Leaf Set, das SR-P2MP-Policy-Modul meldet sie über mögliche Verfahren wie PCEP, BGP oder NETCONF an den Controller. RFC 10018 definiert diese Übergabe nicht im Detail.

Folglich können drei Mengen auseinanderlaufen: die vom Dienst erwarteten Egress-PEs, die in A-D sichtbaren und die vom Controller konsumierten. Eine neue Leaf A-D kann bereits vorhanden sein, während der Controller mit der alten Revision rechnet. Ein Withdraw kann BGP-seitig abgeschlossen sein, während der alte Zweig weiter im PTI liegt.

Zählwerte reichen nicht. Jede Menge braucht Mitglieder, Revision und Zeit; der Controller muss ausweisen, welche Leaf-Set-Version welchem PTI zugrunde liegt.

Teilinstallation ist ein erwartbarer Betriebszustand

RFC 9960 behandelt Fehler bei der Instanziierung eines Replication segment ausdrücklich. Ein lokaler SID-Konflikt kann die Installation verhindern. Ein Knoten sollte Erfolg beziehungsweise Fehler, möglichst mit Grund, melden. Der Controller sollte begrenzt erneut versuchen und nach endgültigem Scheitern alarmieren. Bei fehlenden Segmenten kann er den PTI abbauen; beim Fehler des Root-Segments wird das empfohlen.

Damit entstehen mehrere überprüfbare Stufen: berechnet, angefordert, teilweise bestätigt, vollständig bestätigt, im FIB sichtbar, an der Root aktiviert, per Blatt getestet. Ein einziges ACTIVE löscht diese Stufen.

RFC 9960 beschreibt als Möglichkeit, zuerst Blätter und Zwischenknoten zu installieren und die Root zuletzt. Erst nach den Downstream-Bestätigungen wird die Einspeisung geöffnet. Ob ein Produkt diese Reihenfolge nutzt, ist damit nicht bewiesen. Die Reihenfolge formuliert jedoch eine klare Abnahmefrage.

Eine Controller-Schnittstelle sollte pro Node-ID Replication-SID, gewünschte Revision, Bestätigung, Fehlergrund, Retry-Zahl, Endzustand und Zeit liefern. Der Gesamtstatus muss sich nachvollziehbar daraus berechnen lassen.

Der richtige Baum kann im falschen Dienst enden

Der Tree-SID identifiziert den PTI in der Datenebene. Die Root kapselt, Provider-Knoten replizieren, das Blatt entfernt den Tree-SID und liefert die Payload. Bei einem exklusiven MVPN-P-Tunnel kann der Tree-SID den Dienstkontext hinreichend bestimmen. Bei einem gemeinsam genutzten Tunnel braucht es zusätzlich ein upstream-assigned MPLS Label oder eine SRv6 Multicast Service SID.

RFC 10018 definiert End.DTMC4, End.DTMC6 und End.DTMC46; IANA weist ihnen 76, 77 und 78 zu. Für SRv6 gelten zudem Transpositionsbedingungen. Ein Paket kann deshalb den richtigen Egress erreichen und dennoch in der falschen Multicast-Tabelle oder MVPN landen.

EVPN hat mit Split Horizon eine weitere Korrektheitsgrenze. Bei Ethernet-Segment-Multihoming müssen doppelte BUM-Kopien verhindert werden. SR-MPLS verwendet dafür den ESI-Label-Kontext, SRv6 Arg.FE2 mit End.DT2M. Empfang allein beweist nicht, dass die Kopie zulässig oder einmalig war.

Der Abschlussbeleg braucht PTI, Blatt, MVPN/EVI, Dienstkennung, Split-Horizon-Zustand und Nutzdatenergebnis. Ein Tree-SID ist Forwarding-Identität, kein Tenant-Recht und keine Anwendungsquittung.

Ingress Replication verlagert die Kontrollfläche

Bei Ingress Replication erzeugt die Eingangs-PE je Ausgang eine Kopie und sendet sie über Unicast. Das SR-P2MP-Policy-Modul und der Controller sind nicht beteiligt.

Deshalb unterscheiden sich die Nachweise. IR folgt Egress-Mitgliedschaft, Dienstkennung, gewählter Unicast-/SR-TE-Policy und Einzelkopie. P2MP folgt Controller, PTI, zusammengesetzten Replikationssegmenten, aktiver Instanz und Baum-OAM.

Auch Traffic Engineering ist nicht gleich. IR kann in den beschriebenen Fällen pro Egress behandeln. Im PTI wird innerhalb des Baums repliziert; die Ingress-PE legt eine gemeinsame Behandlung fest.

Ein Fallback von P2MP auf IR benötigt einen Cutover-Datensatz: Ende der Root-Einspeisung, Beginn der Einzelkopien, mögliche Überlappung und Entfernung des alten PTI. Sonst kann Wiederherstellung Duplikate erzeugen.

OAM muss Candidate und Instance-ID nennen

RFC 9961 definiert Ping und Traceroute für eine bestimmte Candidate Path und ihren PTI. Die Prüfungen durchlaufen die zugehörigen Replikationssegmente. Auch inaktive Instanzen sollten separat testbar sein.

Das verhindert, dass Make-Before-Break den Nachweis verwischt. Gleiche Root und gleiche Tree-ID bedeuten nicht gleiche Topologie. Nur die Instance-ID trennt alte und neue Inkarnation.

Bei nicht benachbarten Replikationssegmenten prüft P2MP-OAM die Replikationsstruktur; Unicast-OAM muss den verbindenden Unicast-Pfad prüfen. RFC 9961 nimmt dessen Fehlererkennung nicht für sich in Anspruch.

Eine OAM-Antwort ist außerdem keine Nutzlastbestätigung. Sie beweist nicht den produktiven Service SID, Verlust- und Jittergrenzen, korrektes Split Horizon oder Anwendungsverarbeitung. Dafür braucht jedes Blatt einen an dieselbe PTI-Epoche gebundenen Payload-Canary.

Mengendifferenzen sind die brauchbarste Störungsmeldung

Der Betreiber kann acht Mengen führen:

  • E: vertraglich erwartete Egress-PEs;
  • A: in A-D beziehungsweise Leaf A-D sichtbare Egress-PEs;
  • C: vom Controller für die aktuelle Candidate akzeptierte Blätter;
  • I: Blätter mit vollständig installierter Segmentkette für diesen PTI;
  • F: im Forwarding der aktiven Instanz enthaltene Blätter;
  • O: auf OAM für Candidate und Instance-ID antwortende Blätter;
  • D: im richtigen MVPN-/EVI-Kontext bestätigte Nutzdatenempfänger;
  • W: entfernte Blätter mit bewiesenem Withdraw, Deprogramming und Ruhephase.

Ein strenger Dienst verlangt E = A = C = I = F = O = D. Ein genehmigter Teilbetrieb muss Mitglieder, Grund, Eigentümer, Auswirkung, Ablauf und Rückkehrbedingung nennen. Entfernung ist erst mit Aufnahme in W abgeschlossen.

E − A weist auf Provisioning/A-D, A − C auf Controller-Ingestion, C − I auf Installation, I − F auf die Tragweite der Bestätigung, F − O auf den Pfad und O − D auf Dienstkontext oder Anwendung.

Gleiche Anzahl bedeutet nicht gleiche Mitglieder. Zwölf Antworten, von denen eine zu einem alten Blatt gehört, decken zwölf aktuelle Ziele nicht ab.

Grenzen der öffentlichen Quellen

Die Standards belegen Verfahren und Identitäten. Sie belegen keine benannte Implementierung, Produktunterstützung, Verbreitung, aktuelle Konformität oder den hypothetischen Ausfall in diesem Text.

Ein IANA-Codepunkt beweist Zuweisung, nicht Ausführung. Standards Track ist kein Einsatzbefehl. Die IETF stellt gemeinsame Semantik bereit, aktiviert aber keinen Betreiberbaum.

Das entspricht Lu Hengs Running-Code Primacy: Dokumente dürfen keine Wirkung behaupten, die der laufende Zustand nicht zeigt. Die Minimum Initial Specification mit lokaler Zukunftsentscheidung hält zugleich fest, dass Einsatz- und Risikoentscheidungen lokal bleiben können.

Laufender Zustand ist nicht automatisch richtig. Ein entferntes Blatt, das weiter empfängt, ist reale Evidenz für einen fehlerhaften Rückbau.

Quellen