Zusammenfassung

  • BFD (RFC 5880–5883) meldet Verbindungsausfälle in Millisekunden; die Working Group überarbeitet die Basisdokumente mit dem Ziel, bis Dezember 2026 den Internet-Standard-Status zu erreichen.
  • Die Beweislage gliedert sich in Schichten: Spezifikationstext, zurückgehaltene Errata, von der IESG verifizierte Errata, selbstberichtete Anbieter-Konformität, Interop-Protokolle und ausgelieferte Dokumentation – jede Schicht beweist etwas anderes.
  • Ohne BFD-Diagnosecodes wussten BGP-Sprecher nicht, warum eine Sitzung endete; RFC 9384 führt den Cease-Untercodes 10 „BFD Down“ ein, um diese Lücke zu schließen.
  • Implementierungsdivergenzen sind dokumentiert: Erratum 7240 zu bfd.LocalDiag (gemeldet von Jeffrey Haas), Erratum 5205 zu AdminDown mit unidirektionalem Ausfall und das von der IESG verifizierte RFC-5882-Erratum 8921.
  • Die vorliegende Beweislage rechtfertigt die Bewertung „spezifiziert und teilweise implementiert, nicht dauerhaft verifiziert“ – nicht mehr und nicht weniger.

Die Arbeitsgruppe BFD der IETF überarbeitet derzeit die Grundspezifikationen RFC 5880, 5881, 5882 und 5883 mit einem Meilenstein von Dezember 2026 für die Erhebung zum Internet Standard [https://datatracker.ietf.org/group/bfd/documents/]. Das klingt nach Verwaltungsarbeit, ist aber eine Prüfung, ob ein Mechanismus, der seit über einem Jahrzehnt im Einsatz ist, sein Versprechen auch unter Beweis stellen kann.

Warum Ausfallmeldung eine Reparaturfrage ist

BFD existiert, weil langsameHallo-Erkennungen in Routing-Protokollen Ausfälle zu spät melden. Junos-Dokumentation beschreibt, wie BFD-BGP-Sitzungen Deadbeats erkennen und Alternativen wählen, bevor Datenverkehr blackholed wird [https://www.rfc-editor.org/info/rfc9978/]. FRR dokumentiert dieselbe Funktion für seine BGP-Implementierung [https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bfd-strict-mode/]. Das Problem war nie das Konzept, sondern die Details: Was passiert, wenn die Diagnose fehlt, die Session endet aber?

Die Lücke, die RFC 9384 schließt

Vor RFC 9384 erhielt ein BGP-Sprecher, dessen BFD-Sitzung zusammenbrach, nur das Signal „Sitzung beendet“ – ohne Grund. War es ein Linkausfall? Eine Administrative Abschaltung? Ein Nachbarproblem? RFC 9384 definiert den BGP-Cease-Untercodes 10 „BFD Down“, sodass der Initiator den Grund der Terminierung erfährt [https://www.rfc-editor.org/rfc/rfc9384.html]. Jeffrey Haas, Co-Chair der BFD- und IDR-Arbeitsgruppen und Autor des Dokuments (Jeffrey Haas im IETF Datatracker), verbindet damit zwei Ökosysteme, deren Fehlerzustände zuvor getrennt beobachtet wurden.

Errata als Beweis für gelebte Praxis

Drei dokumentierte Defekte zeigen, wo Spezifikation und Implementierung auseinanderliefen:

  1. Erratum 5205 (RFC 5880): AdminDown gefolgt von einem unidirektionalen Ausfall unterdrückt die Timeout-Anzeige. Ein Nachbarsystem sieht den Ausfall nicht, obwohl er da ist.
  2. Erratum 7240 (RFC 5880), gemeldet von Haas selbst: Implementierungen divergierten bei bfd.LocalDiag, während der Spezifikationstext für korrekt befunden wurde – die Spezifikation wurde also nicht geändert, aber die Divergenz ist aktenkundig [https://datatracker.ietf.org/meeting/118/materials/slides-118-idr-sessb-2-10bgp-bfd-strict-mode-00].
  3. Erratum 8921 (RFC 5882): Von der IESG verifiziert [https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-bfd-subcode]. Verifikation durch die IESG ist die stärkste der drei Stufen; sie bestätigt nicht die Korrektheit der Implementierung, sondern die Ernsthaftigkeit des gemeldeten Defekts.

Diese Schichtung ist der Kern des Beweisproblems: Der Rückhalt „Erratum eingereicht“ ist schwächer als „Erratum verifiziert“, und beide sind schwächer als „Verhalten in ausgelieferter Software korrigiert und dokumentiert“.

Was Selbstauskünfte beweisen können

Eine zweispaltige Konformitätstabelle mit Juniper (Junos 22.3R1) und Arista (EOS 4.29.0) zeigt, welche BFD-Untercodes beide Anbieter selbst berichteten zu unterstützen [https://errata.rfc-editor.org/search/?rfc_number=5880&presentation=records]. Selbstberichtete Konformität ist ein Startpunkt, kein Endpunkt: Sie ist vom Berichterstattenden selbst interpretiert, nicht von Dritten verifiziert. Die IETF-118-Interop-Präsentation ergänzt eine importante Nuance: Eine proprietäre Implementierung unterstützte den Strict-Mode-Entwurf nur in statischer Konfiguration [https://errata.rfc-editor.org/search/?rfc_number=5882&presentation=records].

Der Strict-Mode-Entwurf: Reparatur durch Verhandlung

Der Entwurf draft-ietf-idr-bgp-bfd-strict-mode (Version -19) fügt eine verhandelte Capability hinzu und definiert Hold-down- und Dampening-Verhalten, damit BGP-Sitzungen nicht durch BFD-Restartartefakte abreißen [https://mailarchive.ietf.org/arch/msg/rtg-bfd/w_p72DmhYjZf0Sa31e4sZPPGatw/]. Das Wiederherstellungsproblem ist real: Nach einem Neustart des BFD-Sprechers signalisiert BFD down, BGP zieht die Route zurück, und der Datenverkehr folgt – obwohl der Link niemals ausgefallen war. Der Entwurf adressiert genau diese Wiederherstellungslücke.

Die Gegenprobe: RFC 9978

BFD Stability (RFC 9978) ist ein Beweis dafür, dass die IETF Experimente auch dann veröffentlicht, wenn niemand sie baut: Das Dokument gibt an, dass keine bekannten Implementierungen existieren [https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/bfd-for-bgp-session.html]. Es beweist nichts über Reifegrad – es beweist nur, dass der Prozess Benchmarks dokumentiert, die niemand messen kann. Das ist intellektuell ehrlich und operationell nutzlos, bis jemand implementiert.

Bewertung

Die Beweislage trägt die Aussage: BFD/BGP-Fehlermeldung ist spezifiziert und teilweise implementiert, aber nicht dauerhaft verifiziert. Der Weg zur Verifikation wäre dreistufig: drittparty-verifizierte Interop-Ergebnisse über den Strict-Mode-Entwurf, Bestätigung der LocalDiag-Divergenz in freier Implementierung (FRR) und Errata-Resolution vor der Erhebung zum Internet Standard. Bis dahin bleibt die Last des Nachweises bei den Betreibern.

Quellen