Zusammenfassung

  • draft-geng-grow-bmp-rr-sync-00 schlägt für eine BMP-Sicht die Folge BoRR, Route-Monitoring-Replay und EoRR vor, ohne andere Sitzungen zurückzusetzen.
  • EoRR belegt die Ende-Erklärung des Senders, nicht die vollständige Erzeugung, Übertragung, Aufnahme und Speicherung jeder Route.

Der Collector empfängt EoRR und löscht alle weiterhin als stale markierten Einträge. Das kann den Router exakt abbilden. Es kann ebenso eine unvollständige Kopie sein, wenn ein Batch in einer Queue verloren ging oder ein Live-Withdraw den Replay an der falschen Stelle kreuzte. Beide Abläufe enden mit derselben gültigen Marke.

Das ist die Beweisgrenze von BMP Extension for Non-Disruptive RIB View Synchronization, hochgeladen am 30. September 2026. Revision 00 ist ein aktiver individueller Internet-Draft im Zustand I-D Exists. Im Dokumentkopf steht Standards Track, im Datatracker ist kein angestrebter RFC-Status eingetragen. Es ist weder GROW-Arbeitsgruppendokument noch RFC, IANA-Zuteilung oder Einsatznachweis.

Kleine Reparatur statt großer Neustart

BMP streamt BGP-Zustand an Collector-Systeme. Ausfall, Pufferüberlauf oder Prozessneustart können Sender-RIB und gespeicherte Sicht auseinanderlaufen lassen. Eine komplette BMP-Sitzung oder gar einen BGP-Peer wegen einer beschädigten Sicht zurückzusetzen ist teuer.

Der Vorschlag ergänzt BMP Route-Refresh. Für <Peer, AFI, SAFI> sendet der Router BoRR, danach die vollständige aktive Routenmenge als Route-Monitoring-Nachrichten und schließlich EoRR. Der Collector markiert den alten Bestand stale, erneuert wiederkehrende Einträge und entfernt den Rest am Ende. Das aus RFC 7313 übernommene Muster begrenzt die Auswirkung sinnvoll.

Ein Umschlag ohne Packliste

Revision 00 definiert weder Vorgangs-ID noch Sollzahl, Präfix-Bestätigung, Abschluss-Digest oder unabhängigen Readback. Das Beispiel erlaubt null oder mehr RM-Nachrichten. Null ist bei leerer RIB korrekt und sieht genauso aus, wenn alle Replay-Daten verloren gehen und nur EoRR ankommt.

RFC 7854 verwendet Route Monitoring sowohl für Snapshots als auch für laufende Änderungen, verlangt keine Dump-Reihenfolge und erlaubt Zustandskompression. Der neue Draft kennzeichnet RM-Nachrichten nicht als Replay oder Live und bindet konkurrierende Änderungen nicht an eine nummerierte Epoche. Der Sender kennt seine Absicht; ein fremder Collector muss sie aus TCP-Reihenfolge und lokaler Logik ableiten.

Die Sicht hat mehr als drei Koordinaten

RFC 8671 unterscheidet Adj-RIB-In und Adj-RIB-Out sowie pre- und post-policy. RFC 9069 ergänzt Loc-RIB-Instanzen und gefilterte Sichten. Ein belastbarer Beleg muss Peer-Typ, Distinguisher, BGP-ID, Richtung, Policy-Stufe, Instanz, Filter und Exportkonfiguration festhalten.

Eine vollständige Adj-RIB-In beweist keine Loc-RIB. Eine vollständige Loc-RIB beweist weder FIB-Installation noch Paketpfad oder Dienstergebnis.

TLS zählt fehlende Routen nicht

Der Draft warnt vor gefälschtem EoRR und verlangt IPsec, TLS oder strikte ACLs. Das schützt Identität und Integrität des Kanals. Es beweist nicht, dass ein berechtigter Sender den Bestand vollständig zusammengestellt oder der Collector alles vor der Löschung committed hat.

Die Beweiskette braucht autorisierten Auslöser, vollständige Sichtidentität, Vorgangs-ID und Start-Epoche, BoRR-Empfang, Stale-Commit, Sollzahl oder Digest, Verlust- und Backpressure-Zustand, Ordnung paralleler Live-Änderungen, EoRR auf beiden Seiten, Lösch- und Reject-Zahlen sowie einen abschließenden Vergleich.

Heng Lus Prinzip der minimalen Anfangsspezifikation trennt gemeinsame Interoperabilität von lokaler Beweisführung. Running-Code Primacy fragt, was Systeme tatsächlich beobachtet, gespeichert und verglichen haben. EoRR darf einen Replay schließen; ein eigener Beleg muss seine Vollständigkeit zeigen.

Quellen