Zusammenfassung

  • draft-ietf-pim-multicast-over-srv6-01 nutzt in einem SRv6-Netz nativen IPv6-Multicast. PIM oder ein Controller installiert (S,G)/(*,G) samt RPF- und Ausgangsinterfaces, keine geordnete SID-Liste für den Baum.
  • Flex-Algo kann den Unicast-Pfad zur Quelle und damit RPF beeinflussen. RFC 9502 verlangt jedoch getrennte Teilnahmeankündigungen für das IP-Datenplane und für SR.
  • Abnahme braucht eigene Nachweise für Quellenankündigung, FAD, Teilnehmer, RPF, Zustandsbesitz, Hardwareprogrammierung, Overlay-Mapping, Replikation und Empfänger.

Die Capability-Matrix stellt die falsche Sammelfrage

In Ausschreibungen ist eine Zeile „SRv6/Flex-Algo/Multicast“ praktisch. Sie spart Platz, aber sie verwischt die Ausführungsgrenzen. Ein Router kann am SRv6-Datenplane eines nummerierten Algorithmus teilnehmen und beim gewöhnlichen IPv6-Forwarding desselben Algorithmus fehlen. Er kann die Quelle per Unicast erreichen und trotzdem keinen passenden Multicast-Ausgang programmiert haben. Er kann Pakete replizieren, während die Zuordnung zum Kunden-VPN falsch ist.

RFC 9502 macht IP Flex-Algo ausdrücklich zu einem unabhängigen Datenplane. Die Teilnahme für gewöhnliches IPv4/IPv6 muss getrennt von SR-MPLS oder SRv6 signalisiert werden. RFC 9350 zeigt zudem, dass die Flexible Algorithm Definition aus Rechenart, Metrik und Constraints besteht. Die Nummer 128 allein sagt weder, welche Definition gilt, noch welche Knoten sie unterstützen.

Für den hier betrachteten Multicast ist die IP-Seite entscheidend. PIM-SM leitet das RPF-Interface aus der Unicast-Route zur Quelle ab. Wird das Quellenpräfix für FA128 angekündigt, kann dieser eingeschränkte IP-Pfad den Upstream des Baums bestimmen. Das ist Traffic Engineering durch eine Abhängigkeit, nicht Segment Routing des Multicast-Pakets.

Der Netzname beschreibt nicht die Replikationsanweisung

Die Segment-Routing-Architektur definiert SR als Source Routing für Unicast und lässt die Übertragung des Konzepts auf Multicast außerhalb ihres Umfangs. SRv6 Network Programming liefert Verhaltensweisen für SR-instruierte Pakete. Der PIM-Entwurf 01 wählt dagegen bewusst nativen IPv6-Multicast und nennt die Verteilung orthogonal zu SR; HTML und XML enthalten dieselbe Grenze.

Der aktive Eintrag enthält Quelle, Gruppe, eingehendes RPF-Interface und eine Menge ausgehender Interfaces. Er enthält keine SID-Folge für die Verzweigungen. „Multicast in einem SRv6-Netz“ kann sachlich richtig sein. „Der Multicast-Baum ist segmentgeroutet“ wäre eine zusätzliche Behauptung, die dieser Mechanismus nicht trägt.

Bei einer Topologieänderung wird die Trennung sichtbar. Die Unicast-Route kann bereits auf ein neues Interface zeigen, während PIM Join/Prune noch konvergiert. Pakete auf dem bisherigen Ast scheitern dann am neuen RPF, obwohl Locator und Unicast-SIDs gesund bleiben. Eine zusammengefasste SRv6-Ampel würde den eigentlichen Übergang verbergen.

Zwei Erzeuger brauchen einen lesbaren Besitzvertrag

Neben PIM lässt der Entwurf einen zentralen Controller nativen IPv6-Multicastzustand berechnen und installieren. Das kann spezielle Bäume ermöglichen, ändert aber nicht das Datenplane. Jeder Knoten braucht das richtige Eingangsinterface und seine richtige Ausgangsliste. Eine erfolgreiche API-Antwort beweist weder die Hardwareprogrammierung jedes Astes noch die Paketwirkung.

PIM- und Controller-Bäume dürfen koexistieren, wenn sie unterschiedliche Quellen und Gruppen verwenden. Darin steckt der Besitzvertrag. Treffen beide auf dasselbe (S,G), kann PIM einen zentralen Eintrag altern lassen oder eine Controller-Reconciliation verteilten Zustand überschreiben. Der Entwurf verweist die Northbound-Instanziierung an ein ergänzendes Dokument. Autorisierung, atomare Mehrknotenänderung und Rollback sind hier folglich nicht spezifiziert.

Der Nachweis muss Besitzer, Intent-Version, Ergebnis pro Knoten und Readback aus dem Forwarding enthalten. Sonst können zwei für sich gesunde Control Planes gemeinsam eine fehlerhafte Tabelle erzeugen.

Ein Overlay fügt Bezüge hinzu

Die MVPN-Architektur und die BGP-MVPN-Verfahren trennen Kundenzustand und Provider-Tunnel. RFC 6515 erlaubt IPv4- oder IPv6-Provideradressen, RFC 7716 erweitert auf Global Table Multicast und RFC 8950 erlaubt einen IPv6 Next Hop für IPv4 NLRI.

Im Entwurfsbeispiel baut PIM-SSM den nativen IPv6-Providerbaum, MP-BGP signalisiert PMSI und Kundenrouten, und das Kundenpaket reist als IP-in-IPv6. Next Header 4 bezeichnet inneres IPv4, 41 inneres IPv6. Keiner der Werte belegt das richtige VPN, den Empfängerkreis oder gelungene Replikation. Der Entwurf verlangt keine SRv6-spezifische Overlay-Prozedur. Deshalb muss die Kette Kundenfluss, PMSI, Provider-(S,G), Astzähler, Egress-PE und berechtigter Empfänger erhalten bleiben.

Dokumentfortschritt ist kein Betriebsnachweis

Die eingefrorene Datatracker-API, Dokumentseite und Historie führen einen aktiven PIM-WG-Internet-Draft. Der Kopf nennt Informational als Ziel, ohne angezeigten verantwortlichen AD, Shepherd oder Telechat. Das ist weder RFC noch Implementierungsinventar, Interop-Test oder Messbericht.

Der eingefrorene Vergleich mit Revision 00 zeigt nur Datum, Ablauf, Revisionsnummer und Seitenköpfe als Änderungen. Der Mechanismus blieb gleich. Die Aussage, keine neuen Sicherheitsprobleme über die Referenzen hinaus einzuführen, ist eine Umfangsgrenze; sie authentisiert keinen Controller, vereinheitlicht kein FAD und validiert kein PMSI.

Quellen und Grenzen

Der Korpus umfasst 01 TXT, HTML, XML, 00 TXT, API, Status und Historie. Technischer Kontext: RFC 7761, RFC 6513, RFC 6514, RFC 6515, RFC 7716, RFC 8402, RFC 8950, RFC 9350, RFC 9502 und RFC 8986. Keine Quelle liefert benannte Installation, Herstellermatrix, Konvergenzzeit, Verlustwert oder SLA.