Zusammenfassung

  • Der aktuelle LISP-Multicast-Entwurf beschreibt, dass beim Ausfall des kapselnden ITR eine neue Verteilbaumwurzel aufgebaut und ihr der gewünschte (S-EID,G)-Zustand erneut mitgeteilt werden muss.
  • Anycast kann den RLOC erreichbar halten und die Änderung im Underlay wie eine RPF-Umschaltung aussehen lassen. Der ETR erkennt den Wechsel der physischen Instanz jedoch womöglich nicht; dann lernt der Nachfolger den Empfängerzustand erst beim nächsten periodischen Join/Prune.
  • Daniel Kade schlägt einen Wurzelnachfolge-Beleg und eine ausdrücklich geführte Join-Wiederholschuld vor. Beides sind Instrumente der Betriebsführung, keine neuen Felder in LISP oder PIM.

Eine grüne Adresse kann einen stillen Baum verdecken

Man stelle sich einen Live-Datenstrom vor, der von einem Quellstandort zu Empfängern in mehreren Netzen verteilt wird. Der Ingress Tunnel Router am Quellstandort fällt aus. Das Routing zieht den gemeinsamen Anycast-RLOC zu einem zweiten ITR. Adressproben sind wieder erfolgreich, und im multicastfähigen Underlay wechselt der Reverse Path. Das Netzteam darf zutreffend melden, dass sich die Adresse schnell erholt hat.

Damit ist die Dienstwiederherstellung noch nicht bewiesen. Der alte ITR hielt fest, welche entfernten ETRs welche Kombination aus Quelle und Gruppe abonniert hatten. Die neue Instanz kann für denselben RLOC Pakete annehmen, ohne dieses Wissen zu besitzen. Der Name der Wurzel besteht weiter; ihr Betriebszustand gehörte aber einem verschwundenen Prozess. Bis die Empfängerseite ihre Absicht wiederholt, weiß der Ersatz möglicherweise nicht, welchen inneren Strom er für wen kapseln soll.

Das ist kein Versagen von Anycast. Anycast ermöglicht mehreren Orten, dieselbe Adresse anzukündigen, und überlässt dem Routing die Wahl einer Instanz. Es verspricht keine Replikation des Anwendungs- oder Protokollzustands hinter der Adresse. Der Governance-Fehler entsteht erst, wenn die erneute Erreichbarkeit der Adresse als Nachweis für die lückenlose Fortsetzung jedes zustandsbehafteten Dienstes behandelt wird.

draft-ietf-lisp-rfc6831bis-07 ist ein aktiver Entwurf in der IESG Evaluation. Er zielt auf Proposed Standard und würde bei Annahme den experimentellen RFC 6831 ablösen. Revision 07 stammt vom 11. September 2026. Der geprüfte Unterschied zu Revision 06 besteht überwiegend aus normativer Wortwahl, aktualisierten IGMP-/MLD-Verweisen und redaktioneller Pflege. Dieser Artikel behandelt die fortbestehende Architektur, nicht eine erfundene technische Neuerung der Nummer 07.

Empfängerabsicht und Transportzustand sprechen verschiedene Namen

LISP trennt Endpoint Identifier von Routing Locators. Innerhalb der Standorte bezieht sich die Multicast-Absicht auf Quell-EID und Gruppe. Das Underlay routet auf RLOCs. Diese Trennung hält Identität stabil, wenn sich der Anbindungspunkt ändert, verteilt aber den Multicast-Zustand auf zwei Namensräume.

Ein Empfänger tritt mittels IGMPv3 oder MLDv2 einem (S-EID,G) bei. Sein ETR schlägt die Quell-EID nach und wählt anhand von Priorität und Gewicht im Mapping einen ITR-RLOC des Quellstandorts. In einem Multicast-Underlay versendet der ETR zwei Signale. Ein unicastgekapseltes PIM Join/Prune trägt (S-EID,G) zum ausgewählten ITR. Ein weiteres Join/Prune erzeugt (S-RLOC,G) im Underlay. Das erste beschreibt dem Kapselpunkt den verlangten inneren Strom; das zweite baut den locatorbasierten Verteilbaum.

In einem Unicast-Underlay führt der ITR eine ausdrückliche Liste von RLOCs der empfangenden ETRs und repliziert am Kopf: eine äußere Kopie pro ETR. Auf der Empfängerseite entfernt der ETR den LISP-Header und prüft seine innere Multicast-FIB für (S-EID,G), bevor er an lokale Empfänger weiterleitet.

Diese Nachweise sind nicht austauschbar. Eine Map-Reply nennt mögliche Locators, beweist aber keine Installation des Stroms auf einer physischen Instanz. Ein erfolgreicher RPF-Pfad zeigt die Richtung im Underlay, nicht das EID-Wissen an der Wurzel. Ein lokaler Join kann bestehen bleiben, obwohl der entfernte Kapselpunkt ihn vergessen hat. Ein Paket kann sogar über einen gemeinsam genutzten (RLOC,G)-Baum am ETR eintreffen und mangels passenden inneren Zustands verworfen werden.

Der Betriebsgegenstand ist deshalb keine einzelne „Multicast-Route“. Er ist eine Kette aus Empfängerabsicht, ETR-Grenzzustand, ausgewählter physischer Wurzel, EID-Zustand am ITR, Replikation im Underlay oder am Kopf, ETR-Annahme und Empfängerbeobachtung. Jedes Glied hat einen anderen Verwalter und eine andere Uhr.

Der physische Wechsel erzeugt eine Nachfolgepflicht

Abschnitt 6 des Entwurfs erklärt, weshalb ein ITR-Ausfall über eine gewöhnliche RPF-Änderung hinausgeht. Im Unicast kann lokale Erreichbarkeit eine neue Locator-Auswahl mit wenig Koordination ermöglichen. Bei LISP-Multicast ist der ausgewählte ITR die kapselnde Wurzel des Verteilbaums. Wird er unerreichbar, müssen die beigetretenen ETRs (S-RLOC,G)-Zustand zur neuen Wurzel aufbauen und ihr in einem gekapselten Join/Prune mitteilen, welches (S-EID,G) sie benötigen.

Diese Pflicht hat eine messbare Population: alle betroffenen ETRs. Sie hat ebenso einen bestimmten Gegenstand: die Quell-Gruppen-Zustände, die am Nachfolger vorhanden sein sollen. Standorte erkennen den Ausfall, wählen neu und wiederholen ihr Join-Signal zu unterschiedlichen Zeiten. Ein einzelner Zeitstempel „Failover beendet“ verschleiert diese Verteilung und besonders ihren langsamen Rand.

Anycast macht den Wechsel weniger sichtbar. Nutzen mehrere ITRs denselben RLOC, verschiebt das Routing die Adresse, während das Underlay womöglich nur eine neue RPF-Schnittstelle sieht. Für den entfernten ETR hat sich die Adresse nicht geändert. Ihm kann damit der Auslöser fehlen, (S-EID,G) sofort erneut per Unicast zu senden. Der Entwurf sagt ausdrücklich, dass der neue Anycast-ITR den Zustand eventuell erst beim nächsten periodischen Sendevorgang des ETR erhält.

Für dieses Intervall gibt es keine universelle Zahl. Implementierung, PIM-Timer, Verlust, Konvergenz, Auffrischungsregeln und Underlay-Modus wirken darauf ein. Daraus folgt weder unvermeidlicher Paketverlust noch eine garantierte Dauer. Sicher ist nur: Die Rückkehr der Adresse und die Rückkehr des Zustands sind getrennte Ereignisse.

Join-Wiederholschuld statt pauschaler Entwarnung

Als Join-Wiederholschuld bezeichne ich alle Empfängerabsichten, deren Installation am neuen ITR noch nicht belegt ist. Beim Wechsel der physischen Wurzel wird jeder ETR mit unbelegtem (S-EID,G) zu einem offenen Eintrag. „Schuld“ meint keinen moralischen Vorwurf und keinen bloßen Paketzähler. Der Begriff verhindert, dass eine verteilte Migration hinter einem grünen Adresswert verschwindet.

Ein Eintrag bindet mindestens ETR, S-EID, Gruppe, alten ITR, erwarteten Nachfolger, Generation des letzten Joins, Zeitpunkt der Auffrischung, Underlay-Modus und Schließbedingung. Bietet eine Implementierung eine Bestätigung für installierten Zustand, kann sie beitragen. Andernfalls müssen begrenzte Zustandsprüfung am ITR und Datenbeobachtung am ETR oder an einem kontrollierten Testempfänger verbunden werden.

Ein erfolgreicher Ping zum Anycast-RLOC, eine RIB-Route, ein Mapping-Cache-Eintrag, eine PIM-Nachbarschaft oder ein laufender Prozess begleichen diese Schuld nicht. Keines dieser Signale zeigt, dass genau diese Empfängerabsicht die Grenze zur neuen Instanz überschritten hat. Auch die Rückkehr eines Standorts beweist nichts für andere ETRs, die auf spätere Refresh-Zyklen warten.

Ein Eintrag darf auch wegen eines legitimen Endes geschlossen werden. Der Empfänger kann die Gruppe verlassen haben, die Quelle kann beendet oder die Policy kann den Strom verlegt haben. Der Abschluss nennt deshalb Grund und Autorität: installiert und beobachtet, ausdrücklich zurückgezogen, nach erklärter Regel abgelaufen oder von einer benannten Person als eingeschränkt akzeptiert. Lautloses Verschwinden ist kein Abschlussbeleg.

Der Wurzelnachfolge-Beleg

Der Wurzelnachfolge-Beleg verbindet diese Teile. Er ist Daniel Kades Vorschlag für operative Governance und kein neues LISP-, PIM-, IGMP- oder MLD-Drahtfeld. Er verhindert, dass ein Team den Vorfall allein mit den Signalen der eigenen Schicht schließt.

Zuerst hält der Beleg alte und neue physische ITR-Identität, eigene oder gemeinsame RLOCs, Erkennungsquelle, Zeitpunkt, Vertrauensniveau, verwendete Mapping-Version und Entscheidungsverantwortung fest. Nur die gemeinsame Adresse einzutragen, würde gerade die dahinter verborgene physische Nachfolge auslassen.

Danach folgt der Kontrollfortschritt je betroffenem Umfang: letzter bekannter (S-EID,G)-Zustand der alten Wurzel, neue Locator-Auswahl, RPF-Konvergenz, Join-Generation des ETR, gekapselte Wiederholung und – soweit beobachtbar – installierter Zustand beim Nachfolger. Sammelpunkt und Zeitquelle gehören zu jedem Ereignis. Nicht vergleichbare Uhren dürfen keine scheinbar sichere Kausalfolge erzeugen.

Schließlich erfasst der Beleg die Wirkung: erstes am neuen ITR angenommenes Paket, erste gültige Annahme an jedem Stichproben-ETR, Sequenz- oder Anwendungskontinuität, Verlust- und Duplikatfenster, wegen fehlenden inneren Zustands verworfener unerwünschter Verkehr und Alter der Restschuld. Routerbelege dürfen nicht als gesunde Anwendung beschriftet werden.

Auch die Rückfallautorität gehört hinein. Je nach System kann sie einen bestimmten Unicast-Locator wiederherstellen, den Nachfolger entleeren, einen kontrollierten Join-Refresh auslösen, einen Strom verlagern oder zeitweise Head-End-Replikation akzeptieren. Dieser Artikel erfindet keinen allgemeinen Befehl; er verlangt eine klare Aktion, Reichweite, Entscheidungsperson und Prüfung.

Mit der Replikation wandert der Beweis

Der Entwurf erlaubt Replikation innerhalb eines Standorts, in einem Transitrouter des Underlays, an ETRs oder an ITRs. Ein Multicast-Underlay trägt mehr Zwischenzustand. Ein Unicast-Underlay verlagert Kosten zu Kopien und Bandbreite am Quellstandort. Map-Reply-Priorität und -Gewicht können zudem verschiedene Empfänger zu verschiedenen ITRs führen.

Die Rechenschaft muss der Topologie folgen. Eine ETR-Liste am ITR ist ein Replikationsplan, kein Zustellbeleg. Ein gesunder (S-RLOC,G)-Baum kann mehrere innere Quellen zusammenfassen. Laut Entwurf kann ein Standort deshalb Verkehr empfangen, den er nicht angefordert hat, und ihn nach der inneren Prüfung verwerfen. Das Verwerfen ist korrekt, doch die gemeinsame Kapazität wurde bereits beansprucht.

Sicherheit und Resilienz treffen sich hier. Der Text beschreibt, wie ein bösartiger Empfängerstandort unerwünschte Daten zu legitimen Standorten im gemeinsamen Baum bringen kann. „Das Paket erreichte den ETR“ kann Erfolg, Verschwendung oder Angriff bedeuten. Erst innerer Zustand und erwartete Empfängermenge geben der Beobachtung ihren Sinn.

Die Diagnosegrenze bleibt offen

Detaillierte Locator-Erreichbarkeit, bestimmte mPITR-Verfahren und das mtrace-Design für LISP-Multicast liegen außerhalb des Entwurfs. Für mtrace heißt es, die Gestaltung müsse auf Mtrace Version 2 aufbauen und sei noch zu bestimmen. Eine generische Pfaddiagnose liefert daher keine vollständige Sicht über EID- und RLOC-Namensraum hinweg.

Jede Messung sollte ihre Schicht nennen. Ein Underlay-Test beschreibt den RLOC-Pfad; ITR-Prüfung zeigt (S-EID,G); ETR-Zähler zeigen Entkapselung und innere Suche; Empfängerbeobachtung zeigt nutzbare Ankunft. Ihre Korrelation kann eine Dienstbehauptung tragen. Eine einzelne Messung kann die anderen nicht ersetzen.

Ein IETF-Entwurf soll Mechanismus und Grenzen spezifizieren, nicht ein universelles Beobachtungsprodukt liefern. Betreiber müssen deshalb präzise bleiben. „Anycast-Failover erfolgreich“ ist eine Aussage über die Adresse. Multicast-Wiederherstellung braucht zusätzlich Zustand und Empfängernachweis.

Quellen

  1. Aktueller LISP-Multicast-Entwurf
  2. Entwurfshistorie
  3. Datatracker-API-Datensatz
  4. Revision 07 als HTML
  5. Revision 07 als Text
  6. Vergleich Revision 06 zu 07
  7. LISP Working Group
  8. RFC 6831
  9. RFC 9300: LISP Data Plane
  10. RFC 9301: LISP Control Plane
  11. RFC 8059: PIM Join Attributes für LISP
  12. RFC 7761: PIM
  13. RFC 8487: Mtrace Version 2
  14. RFC 9776: IGMPv3
  15. RFC 9777: MLDv2
  16. RFC 7799: Terminologie für Messungen
  17. XML-Quelle der Revision 07