Zusammenfassung

  • draft-ietf-bier-bfd-12 beschreibt P2MP BFD über BIER. Verliert ein BFER die Kontinuität vom BFIR, sendet es eine unaufgeforderte IP/UDP-Unicast-Meldung über einen Pfad, der vom Multicast-Verteilbaum disjunkt sein muss.
  • Final vom BFIR bestätigt Zuordnung und Empfang der Meldung. Es lokalisiert den Fehler nicht, spricht nicht für alle Enden und belegt weder Baumreparatur noch Anwendungszustellung.

Am Ende des Baums läuft die Erkennungszeit ab. Das BFER setzt Down, nennt Control Detection Time Expired und meldet den Befund über UDP 4784. Der BFIR antwortet Final. Die Alarmstrecke funktioniert; die überwachte Strecke kann weiterhin gestört sein.

Diese Trennung prägt Revision 12 von BIER BFD vom 29. September 2026. Der aktive Standards-Track-Internet-Draft der BIER Working Group läuft am 2. April 2027 ab. Er ist weder RFC noch abgeschlossene IETF-Entscheidung, IANA-Zuteilung, Implementierung oder Einsatzbericht. Die beantragten Werte bleiben TBD1, TBD2 und TBD3.

Ein Tail beobachtet nur die Richtung vom Head

Der BFIR ist MultipointHead und sendet BFD-Control-Pakete in BIER an ausgewählte BFERs. Jedes Tail überwacht den ankommenden Strom. Läuft sein Detection Timer aus, kann es den Verlust erklären.

Die Aussage lautet genau: Dieses Tail erhielt in dieser Sitzung die erwarteten Pakete dieses Heads nicht. Sie benennt weder Leitung noch Zwischenknoten oder Replikationsfehler. Andere BFER können unverändert empfangen. Ein lokaler Ablauf ist kein globaler Baumzustand.

Der Bootstrap kann BIER Ping, BGP oder statische Konfiguration nutzen. BIER Ping trägt den Zielbestand im Target SI-BitString und My Discriminator in einem vorgeschlagenen TLV. Ändert sich der Discriminator, muss der Bootstrap wiederholt werden. Verteilte Parameter beweisen jedoch weder die Installation bei jedem Tail noch den tatsächlichen Weg späterer Pakete.

Der Discriminator braucht den BFIR-Kontext

Gewöhnliches BFD wählt am Empfänger mit Your Discriminator die Sitzung. Ein P2MP-Tail übernimmt dagegen My Discriminator vom MultipointHead und benötigt weiteren Kontext. Derselbe Zahlenwert kann unter einem anderen Head existieren.

BIER liefert BFIR-id. Deshalb verlangt Revision 12 am Tail den Schlüssel (BFIR-id, My Discriminator). Wer nur die vier Oktette speichert, entfernt die Herkunft und kann einen Alarm der falschen Wurzel zuordnen.

Zum belastbaren Datensatz gehören außerdem Sub-Domain, Zielmenge, lokales BFER, Bootstrap-Quelle und Änderungshistorie. Zusammengesetzte Identität ist die Voraussetzung für richtige Zurechnung.

Der Rückweg soll das Schicksal des Baums nicht teilen

Nach Erkennung setzt das BFER Poll, State Down und Diagnostic Control Detection Time Expired. Your Discriminator erhält den My Discriminator der ausgefallenen Sitzung. Das Paket geht per IP/UDP Unicast an den BFIR, Zielport 4784.

Dieser Rückweg muss vom Multicast-Verteilbaum disjunkt sein. Sonst könnte derselbe Schaden sowohl den Messstrom als auch dessen Alarm verschlucken. Ein separater Weg lässt den Befund außerhalb seines Fehlerpfads sichtbar werden.

Der Empfang beweist dennoch nur die Reise dieses Unicast-Pakets. Er verrät nicht, wo die Vorwärtsrichtung gebrochen ist. Der Beleg muss die abgelaufene BIER-Sitzung und Route, Interfaces sowie Sicherheitskontext der Rückmeldung getrennt bewahren.

Logische Trennung kann physische Gemeinsamkeit verdecken: Linecard, Kabelkanal, Stromdomäne oder Control-Plane-Queue. Der Draft formuliert die Forderung, aber der Betreiber muss seine realen Fehlerdomänen prüfen.

Final schließt den Alarm, nicht den Vorfall

Das BFER meldet einmal pro Sekunde, bis ein gültiges Final ankommt oder der Defekt verschwindet. Zusätzlich sollte es drei Pakete in pseudozufälligen Abständen innerhalb einer Sekunde senden.

Der BFIR ordnet über Your Discriminator zu und antwortet unicast mit Final. Das Tail weiß nun, dass der Head den Befund erkannt hat. Es weiß nicht, dass der Baum repariert, eine Route geändert oder Multicast wieder an eine Anwendung geliefert wurde.

Auch ein Ende der Wiederholungen ist ohne Ursache mehrdeutig: Final und lokale Defektbereinigung sind beide möglich. Automatisierung muss Annahme einer Beobachtung, Freigabe einer Änderung und Bestätigung der Wiederherstellung trennen.

Stille Tails sind nicht automatisch gesund

Ein gemeinsamer Fehler kann viele BFER treffen und eine Meldespitze zu einem BFIR erzeugen. Revision 12 fordert, die Zahl der zur Control Plane weitergereichten BFD-Meldungen zu kontrollieren.

Der Schutz ist notwendig, macht aber Unsichtbarkeit möglich. Ein stilles Tail kann gesund sein, auch den Rückweg verloren haben, ohne installierte Sitzung arbeiten oder vor der Verarbeitung begrenzt worden sein. Ein empfangener Alarm klassifiziert nicht den Rest.

Betreiber müssen erwartete aktive Tails, installierte Tupel, Down-Meldungen, Eingangsverluste, zugelassene Pakete, Zuordnungen, Final-Antworten und spätere Kontinuität abgleichen. Limiter-Zähler erklären, welche negativen Beobachtungen das System überhaupt sehen konnte.

Die Beweiskette umfasst exakte Revision, Bootstrap-Autorität, zusammengesetzte Identität, letztes gültiges Paket, Ablauf, Alarmbau, Rückweg, Head-Zuordnung, Final oder Defektende, Population, Diagnose, Reparatur, erneutes BFD und Anwendungsergebnis. Keine Stufe beweist die nächste.

Heng Lus Prinzip der minimalen Anfangsspezifikation passt dazu. Die gemeinsame Schicht normiert Identität, Signal, Wiederholung und Empfangsbestätigung. Tail-Auswahl, echte Vielfalt, Control-Plane-Schutz, Diagnose und Reparatur bleiben lokale Entscheidungen. Veröffentlichung ist keine Adoption; laufender Code, Pakete und Ergebnisse sind es.

Quellen