Zusammenfassung

  • Die Join-Attribute-Option im PIM Hello von RFC 5384 erklärt nur die Bereitschaft, eine Encoded-Source Address des Typs 1 zu empfangen. Sie bestätigt nicht das Verständnis jedes darin enthaltenen Attributtyps.
  • Treffen unterschiedliche Werte desselben Typs aus mehreren Nachbarschaften ein, wählt das generische Verfahren die numerisch kleinste Adresse, sofern der Attributstandard keine eigene Regel enthält. Für IPv6 gilt die Link-Local-Adresse; bei gleicher Adresse entscheidet der Interface-Index. Das ist ein Konvergenzergebnis, kein Autoritäts- oder Liefernachweis.

Eine Rangfolge der Nachbarn ist keine Rangfolge der Rechte

Der Konflikt braucht keinen fehlerhaften Absender. Zwei Downstream-Router senden für dieselbe Kombination aus Quelle und Gruppe jeweils einen gültigen Join. Beide tragen denselben Attributtyp, aber verschiedene Werte. Der Upstream-Router muss einen Zustand bilden und gegebenenfalls genau ein Ergebnis weiterleiten.

RFC 5384 ordnet die Lieferanten statt der Argumente. Das Attribut aus der PIM-Nachbarschaft mit der numerisch kleinsten IP-Adresse gewinnt. Für IPv6 wird die Link-Local-Adresse verglichen; identische Adressen werden anhand des Interface-Index geordnet. Eine spätere Attributspezifikation darf ein fachlich passenderes Verfahren festlegen.

Die allgemeine Regel ist nützlich, weil gleiche Eingaben zu einer reproduzierbaren Auswahl führen. Sie prüft jedoch keinen Change-Request, keinen Service-Eigentümer und keine betriebliche Priorität. Eine Umnummerierung kann den Gewinner ändern, obwohl beide angeforderten Werte unverändert bleiben.

Wenn ein Dashboard nur den aktiven Wert zeigt, sieht die Auswahl wie Einigung aus. Tatsächlich blieb der Widerspruch bestehen und wurde durch eine stabile Sortierung verdeckt. Ein Prüfbericht muss daher nicht nur den Gewinner, sondern auch die unterlegenen Sätze und die angewandte Regel enthalten.

Fähigkeit für das Format ist keine Fähigkeit für die Bedeutung

Ein PIM Join identifiziert den Verteilbaum über eine Encoded-Source Address im Kontext der Gruppenadresse. RFC 5384 weist dem Encoding Type 1 die Möglichkeit zu, TLV-Join-Attribute an diesen Baum zu binden. Typ 1 muss mindestens ein Attribut enthalten; ohne Attribute wird Typ 0 verwendet.

Ein Router darf Typ 1 nicht über ein Interface senden, wenn dort ein PIM-Nachbar die Join-Attribute-Option im Hello nicht angekündigt hat. Auch ein Nachbar, der nicht der Upstream ist, muss für Join-Unterdrückung oder -Überschreibung parsen können.

Die Aussage der Option bleibt eng. Ein Router mit dieser Option versteht nicht zwangsläufig alle möglichen Attributtypen. RFC 5384 definiert keine allgemeine Hello-Option pro Typ. Der Nachweis lautet deshalb: Der Nachbar kann dem Typ-1-Umschlag begegnen. Er lautet nicht: Alle Beteiligten teilen dessen Semantik.

RFC 6420 ergänzt für MT-ID eine eigene Fähigkeit, Validierung und Konfliktbehandlung. RFC 6807 gibt Population Count eine separate Option. RFC 7887 kodiert gemeinsame Werte hierarchisch für Nachricht, Gruppe oder Quelle, ohne deren Bedeutung zu ändern. Die Erweiterungen belegen, dass das Grundformat kein vollständiger Fachvertrag ist.

In einer Abnahme müssen Typ-1-Parser, konkrete Attributtypen, Softwarestand, Interface-Geltung und lokale Richtlinie getrennt dokumentiert werden. Ein Produktmerkmal „Join Attributes“ ist zu grob.

Ein unbekanntes Attribut kann weitergetragen werden

Das F-Bit bestimmt die Behandlung eines unbekannten Typs. Bei F=1 ist das Attribut transitiv und muss weitergeleitet werden. Bei F=0 ist es nicht transitiv und muss verworfen werden. Die übrigen Attribute bleiben erhalten; bleibt keines übrig, wird ein Join mit Typ 0 gesendet.

Das Auftauchen eines Werts weiter oben im Netz beweist damit nicht, dass jeder Hop ihn verstanden hat. Ein Router kann Bytes pflichtgemäß transportieren, deren Bedeutung er nicht auswertet.

Er kann außerdem widersprüchliche transitive Sätze desselben unbekannten Typs von verschiedenen Nachbarschaften erhalten. Sind Anzahl und Inhalte nicht bytegleich, muss das generische Konfliktverfahren angewandt werden. Das Gerät kann also eine unbekannte Bedeutung anhand der Adressordnung auswählen.

Die Telemetrie sollte die Schritte ausdrücklich unterscheiden: empfangen, Umschlag geparst, Typ verstanden, unbekannt weitergeleitet, unbekannt verworfen, Kandidat ausgewählt. Der Begriff „validiert“ verlangt einen zusätzlichen Semantik- und Berechtigungsnachweis.

Der Zustand bleibt an die Herkunft gebunden

Beeinflusst ein Attribut die Baumkonstruktion oder den weitergeleiteten Satz, fordert RFC 5384 die Zuordnung des Zustands zu der empfangenden Nachbarschaft. Dadurch kann ein Prune oder der Ablauf genau dieser Adjazenz die richtigen Attribute zurückziehen.

Unterlegene Sätze dürfen gespeichert werden. Fällt die Nachbarschaft des Gewinners aus, kann der nächste Kandidat in der Reihenfolge sofort wirksam werden. Die schnelle Konvergenz ist betrieblich wertvoll.

Sie kann jedoch die aktive Steuerungsabsicht ändern. Der neue Wert war womöglich lange vorhanden, aber unterdrückt. Der Datenstrom kann weiterlaufen, während eine andere Nachbarschaft den Baum bestimmt. Wer nur den Endzustand protokolliert, verwechselt genehmigte Änderung mit failoverbedingter Beförderung.

Ein belastbarer Datensatz umfasst alle Adjazenzsätze, Adresse, Eingangsinterface, Auswahlregel, Gewinner, Alternativen und Übergangsgrund. Er erhält die Verantwortungskette über den Ausfall hinweg.

Ein neuer Join ersetzt den gesamten Satz

Attributänderungen sind keine Deltas. Unterscheidet sich der neue Satz vom vorherigen, wird er zum vollständigen neuen Satz. Nicht mehr vorhandene Attribute gelten als zurückgezogen. Die leere Menge wird mit Typ 0 dargestellt. Ein Prune zieht ebenfalls die Attribute seiner Nachbarschaft zurück.

Sendete ein Nachbar zuvor A und B, später nur B, ist A verschwunden, obwohl kein gesonderter Lösch-TLV eintrifft. Ein Sammler, der lediglich neue Werte anhängt, erzeugt einen Geisterzustand.

RFC 7887 erlaubt breitere Geltungsbereiche auf Nachrichten-, Gruppen- und Quellenebene. Kompakte Darstellung verringert Bytes, nicht die Wirkung eines falschen Werts. Änderungsnachweise müssen den vollständigen Vorher- und Nachher-Zustand für jede Ebene bewahren.

Authentizität löst den Zuständigkeitskonflikt nicht

RFC 5384 bindet die Sicherheit des Attributs an die Sicherheit des PIM-Pakets und verweist zusätzliche Risiken an die jeweilige Attributspezifikation. RFC 5796 kann Herkunft und Integrität linklokaler PIM-Nachrichten absichern.

Zwei authentisierte Nachbarn können trotzdem widersprechen. Kryptografie zeigt, wer die Bytes gesendet hat. Sie entscheidet nicht, welche Organisationseinheit den Dienst steuert oder welcher Antrag gültig ist. Aus einer kleineren Adresse wird kein größeres Mandat.

Eine externe Berechtigungsrichtlinie muss Principals, Quell- und Gruppenbereiche, erlaubte Typen und Werte, lokale Prioritäten sowie Eskalation verbinden. Wenn bei MT-ID nach RFC 6420 lokale Konfiguration Vorrang hat, gehören diese Konfiguration und ihre Freigabe in die Beweiskette.

Kontrollzustand ist noch kein Dienstergebnis

Auch ein verstandenes, ausgewähltes und authentisiertes Attribut ist zunächst Kontrollplanbeleg. Es kann Upstream-Nachbar oder RPF-Topologie beeinflussen, beweist aber weder installierten Multicast-Zustand noch tatsächlichen Pfad, Duplikatfreiheit, berechtigte Empfänger oder Anwendungserfolg.

Die Kette muss getrennt bleiben: konfigurierte Absicht, Fähigkeiten, empfangener Join, Interpretation, Konfliktauswahl, Upstream-Join, installierter Zustand, Paketbeobachtung und Empfängergebnis. Jede Stufe kann nach erfolgreicher Vorstufe scheitern.

Die bestehende RFC-9798-Berichterstattung besitzt Receiver RLOC, Underlay-Gruppenwahl, ITR-Replikation und Zustellbelege. Der RFC-9739-Artikel besitzt PIM Light ohne Hello, DR, Assert und Fehlerentzug. Hier geht es ausschließlich um die begrenzte Autorität des generischen RFC-5384-Verfahrens.

Abnahme mit sichtbarem Verlierer

Ein Labor erhält zwei Downstream-Adjazenzen und einen Upstream-Router. Zuerst wird Typ-1-Fähigkeit aller Nachbarn geprüft. Für einen definierten Attributtyp werden Join-Bytes, Baumkennung, Adresse, Interface und Zeit erfasst.

Dann kommen verschiedene Werte desselben Typs. Die Prüfung stellt fest, ob eine typspezifische Regel existiert; andernfalls muss die kleinere Adresse gewinnen. Nur die Nummerierung wird vertauscht und der Versuch wiederholt. Danach läuft die Sieger-Adjazenz ab, der gespeicherte Kandidat wird beobachtet und ein Satz A+B durch B ersetzt.

Ein unbekannter transitiver und ein unbekannter nicht transitiver Typ testen Weiterleitung und Verwerfen. Abschließend werden Kontrollzustand, Paketspur und Canary-Empfänger getrennt verglichen. Der Bericht muss „X wurde nach Regel Y gewählt“ formulieren können, ohne daraus „X war berechtigt“ oder „der Dienst wurde geliefert“ zu machen.

Quellen