Zusammenfassung

  • draft-ietf-bier-source-protection-11 beschreibt, wie der Pfad vom Backup-BFIR zum ausgewählten BFIR ausfallen kann, während die Pfade des ausgewählten BFIR zu den BFER weiter funktionieren. Eine Übernahme ist dann unnötig und kann Pakete verdoppeln.
  • Auch ein rückwärts laufender Ping bildet den Vorwärtspfad nicht automatisch ab. Ohne Co-Routing kann er scheitern, obwohl der Multicast funktioniert, oder antworten, obwohl der Dienstpfad defekt ist.
  • Beobachtungsidentität, Detektorergebnis, Standby-Modus, Umschaltbefugnis, Verlust oder Duplikation, Empfängerzustand und Anwendungsergebnis brauchen getrennte Belege. Revision 11 bleibt ein informatorischer Internet-Draft.

Das Backup hatte eine korrekte Information: Auf seiner Session zum Primären kamen die erwarteten Kontrollpakete nicht mehr an. Daraus entstand eine falsche Gesamterzählung: Der Primäre sei tot, alle Empfänger hätten den Dienst verloren, und das Backup müsse senden.

Tatsächlich war nur der seitliche Pfad zwischen beiden Ingress-Routern unterbrochen. Der Primäre belieferte die BFER weiter. Als das Backup übernahm, lagen zwei Quellen auf demselben Flow. Der Schutzmechanismus hatte seinen eigenen Sichtverlust mit einem Dienstausfall verwechselt.

Genau diese Szene macht Revision 11 des BIER-Entwurfs wertvoll. Die operative Frage lautet nicht nur, wie schnell BFD erkennt. Sie lautet, welches beobachtete Ereignis welche Änderung legitimieren darf.

Drei gerichtete Flächen statt eines einzigen Zustands

Nach RFC 8279 bringt ein BFIR Multicast-Pakete in die BIER-Domäne, BFER nehmen sie entgegen, und der Kern leitet anhand des BitString ohne Multicast-Per-Flow-State weiter. Für jeden Flow wählt ein BFER dennoch einen Upstream Multicast Hop. Overlay-Protokolle verteilen Auswahlwissen; BIER transportiert Daten.

Der Entwurf nennt den gewählten Ingress S-BFIR und die Alternative B-BFIR. Verschiedene BFER dürfen verschiedene Primäre wählen. Zwei Ingress-Router können unterschiedliche Empfängergruppen bedienen. „Der Primäre ist ausgefallen“ hat ohne Flow- und Empfängerscope keine eindeutige Bedeutung.

Mindestens drei Pfade sind zu unterscheiden:

  1. B-BFIR zu S-BFIR als Beobachtungspfad des Backups;
  2. S-BFIR zu jedem BFER als geschützter Vorwärtspfad;
  3. BFER zu S-BFIR als Rückweg einer Ping-Anfrage.

Sie können Links teilen, müssen es aber nicht. Der Ausfall des ersten Pfads beweist, dass das Backup den Primären über diesen Pfad nicht mehr sieht. Er beweist weder den Knotenausfall noch den Ausfall der Vorwärtspfade.

Im Warm-Standby-Beispiel verliert BFIR2 die Verbindung zu BFIR1 und deutet dies als BFIR1-Ausfall. BFIR2 übernimmt. Die Wege von BFIR1 zu allen oder einigen BFER sind weiterhin intakt. Der Entwurf bezeichnet das Umschalten als unnötig und nennt doppelte Pakete im Netz und an den BFER als Folge.

Der Gegenfehler ist ebenso möglich: Der Ingress-zu-Ingress-Pfad ist gesund, während ein BFIR1-zu-BFER-Pfad gestört ist. Ein grüner Detektor kann neben einem roten Dienst existieren.

Down braucht ein Subjekt

RFC 5880 definiert BFD für einen bestimmten Weiterleitungspfad. RFC 8562 erweitert das Verfahren auf Multipoint. Der BIER-BFD-Entwurf ergänzt Bootstrap und Active-Tail-Benachrichtigungen. Schnelligkeit erweitert den Geltungsbereich eines Messwerts nicht.

Gespeicherter Zustand Tragfähige Aussage Unzulässige Erweiterung
BFD Down zwischen Backup und Auswahl Diese Session überschritt den Schwellwert Alle BFER-Pfade sind ausgefallen
Rückwärts-Ping ohne Antwort Diese Sonde wurde nicht abgeschlossen Der Vorwärts-Multicast steht
Tail überschreitet Detection Time Dort fehlten erwartete Kontrollpakete Alle Empfänger verloren den Flow
BFER wählt neuen UMH Die Auswahl dieses Empfängers änderte sich Die Anwendung ist wiederhergestellt
Backup beginnt zu senden Eine zweite Quelle ist aktiv Alle Duplikate werden verworfen

Der Beleg benötigt Richtung, Endpunkte, Subdomäne, Paketbehandlung, Entropie oder Pfadauswahl, Discriminator, Intervall, Schwellwert und Traffic-Klasse. Ein isoliertes Down verliert den Gegenstand der Beobachtung.

Ein Ping kann in beiden Richtungen irren

Ein BFER kann BFIR1 anpingen und nach mehreren fehlenden Antworten als gescheiterten UMH behandeln. Der geschützte Multicast läuft jedoch von BFIR1 zum BFER; der Request läuft in Gegenrichtung.

Bei asymmetrischem Routing sind diese Wege verschieden. Der Entwurf nennt beide falschen Ergebnisse: Ping scheitert bei gesundem Flow, oder Ping funktioniert bei defektem Multicast-Pfad. Deshalb soll der Request mit dem überwachten Vorwärtspfad co-geroutet werden.

Co-Routing beweist noch keine Anwendungslieferung. Es verbessert die Repräsentativität der Netzbeobachtung. Vollständigkeit, Reihenfolge und Duplikatfreiheit bleiben Empfänger- und Anwendungsbelege.

Cold, warm und hot verteilen Befugnisse

Der allgemeine Multicast-Entwurf unterscheidet drei Modi.

Cold Standby signalisiert die Alternative erst nach der Empfängerentscheidung. Es gibt keinen ständigen Doppelverkehr, aber Signalisierung und Konvergenz können Pakete verlieren.

Warm Standby hält den Backup-Ingress vorbereitet. Nur der Primäre sendet normal. Das Backup startet schneller, kann aber eine Empfängerstrecke beurteilen wollen, die es nicht direkt beobachtet.

Hot Standby lässt beide senden; der BFER verwirft die nicht ausgewählte Kopie. Die Umschaltlücke wird kleiner, während doppelte Bandbreite und korrekte Filterung Dauerpflicht werden.

Das sind keine Reifestufen. Sie verschieben Verlust, Bandbreite, Synchronisation, Fehlerautorität und Filterung. Eine Anforderung „schnellster Failover“ lässt das eigentliche Kontrollmodell offen.

Empfänger dürfen unterschiedliche Gegenwart haben

BFER können verschiedene S-BFIR und verschiedene Timeouts besitzen. Einer hat bereits zu BFIR2 gewechselt, ein anderer bleibt bei BFIR1, ein dritter wartet noch. Ein globales primary_failed verwischt legitime lokale Entscheidungen und unkontrollierte Doppelherrschaft.

Der kleinste Entscheidungsschlüssel umfasst Flow, BFER oder Gruppe, S-BFIR, Beobachtungspfad, Detektor, Schwellwert und vorherigen Zustand. Danach müssen Control Receipt und Effect Receipt getrennt bleiben: Wer änderte den UMH nach welcher Regel? Wann begannen und stoppten beide Quellen tatsächlich? Welche Verluste, Duplikate und Reorderings sah jeder Empfänger? Was sah die Anwendung?

Ein Paket von BFIR2 beweist nur eine erfolgreiche Einzelübertragung, nicht das Ende von BFIR1 oder die Konvergenz der Empfänger.

Arbeitsstand ist kein Betriebsnachweis

Revision 11 ist ein BIER-Working-Group-Internet-Draft vom 1. Oktober 2026 mit Informational-Absicht. Er ist kein RFC, beantragt keine IANA-Zuweisung und verweist bei Security auf BIER, Multipoint BFD, MVPN-Failover, BIER Ping und BIER BFD.

Der Text belegt die erkannte Gefahr von Pfadverwechslung, Fehlurteil und unnötiger Übernahme. Er belegt keine Herstellerimplementierung, Interoperabilität, Einführung oder reale Wiederherstellung.

Lu Hengs Reality Layers bindet den symbolischen Detektorzustand an die physische Fläche, die gemessen wurde. The Policy Mirror verlangt Akteur, Regel, Scope und Konsequenz, sobald ein Signal die Topologie ändern darf.

Failover-Beleg

Zu speichern sind Flow; S-BFIR/B-BFIR; BFER-Menge; Standby-Modus; Overlay und alte Auswahl; Detektor/Session; gerichteter Messpfad; Gleichbehandlung von Probe und Flow; Timer, Schwelle und Fehlpakete; autorisierender Akteur; alter und neuer UMH; tatsächlicher Start und Stopp beider Quellen; Verlust-, Duplikat- und Reordering-Zähler; Empfängerakzeptanz; Anwendungsergebnis.

Ohne Co-Routing-Beleg heißt der Zustand pfadaequivalenz_unbestaetigt. Ohne Sicht auf den Empfängerpfad heißt er empfaengerpfad_unbekannt. Benannte Ungewissheit begrenzt Automatisierung; verschwiegene Ungewissheit erhält Macht.

Quellen