Zusammenfassung

  • Der individuelle Entwurf zur ROV-Benchmarkmethodik misst vom Senden der ersten einschlägigen RTR-Update-PDU bis zur Stabilität von BGP RIB und FIB. Eine zweite Messung beginnt erst nach der Installation des betreffenden VRP-Updates und endet am selben Punkt.
  • Die erste Spanne umfasst RTR-Übertragung, Installation, erneute Routenvalidierung und BGP-Konvergenz. Die zweite isoliert die Zeit nach der Installation. Wer nur eine veröffentlicht, soll laut Entwurf angeben, welche es ist.
  • Die Tabellengrößen definieren Testlasten; Anhang B enthält außerdem Messungen an einem BIRD/Linux-Prüfling, die keine Geschwindigkeiten anderer Router belegen. Für einen Vergleich braucht es benannte Start- und Endereignisse, Last und Wiederholungen.

Ein neues Validierungsergebnis ändert nicht beim Eintreffen des ersten Pakets die Weiterleitung. Der Router muss die Daten vom Cache annehmen, seine lokale VRP-Tabelle aktualisieren, betroffene BGP-Pfade neu einordnen, einen Pfad auswählen und die FIB programmieren. Erst am letzten Punkt kann der Betreiber sagen, dass die neue Information in der Weiterleitung angekommen ist. Beginnt die Uhr nach der Installation, fehlen Übertragung und Einbau in der ausgewiesenen Zeit.

RFC 8210 beschreibt den RPKI-to-Router-Austausch zwischen Cache und Router. RFC 6811 klassifiziert den Ursprung einer BGP-Route als Valid, Invalid oder NotFound; die Reaktion ist Sache der lokalen Routingpolitik. Eine Klassifikation ist noch keine FIB-Änderung. Dazwischen liegen Datenübernahme, Neuberechnung, Pfadwahl und Programmierung. Die Sammelbezeichnung „ROV-Latenz“ verdeckt, welchen dieser Schritte eine Zahl überhaupt erfasst.

Der Entwurf in Revision 00 legt im VRP-ausgelösten Konvergenztest zwei Startpunkte fest. Für die gesamte Reaktion beginnt der Timer, wenn der RTR-Emulator die erste relevante Update-PDU sendet. Er stoppt erst, wenn BGP RIB und FIB stabil sind. Der zweite Timer startet mit Abschluss der Installation des relevanten VRP-Updates im Prüfling und stoppt am selben stabilen Endpunkt. Der volle Wert beantwortet die Frage nach der Reaktion des Systems auf neue Daten. Der kürzere Wert hilft, die anschließende BGP-Phase einzugrenzen.

Das hat Folgen für Ausschreibungen. Erreichen zwei Geräte nach einem Update gleichzeitig eine stabile FIB, zeigt das Gerät mit dem späteren Messbeginn eine kürzere Spanne. Das ist Arithmetik, kein Vorwurf gegen einen bestimmten Hersteller. Für ein Urteil über ein konkretes Gerät fehlen die Zeitstempel beider Starts und des gemeinsamen Endes aus demselben Lauf.

Der Text bietet weitere Messstationen. Der Installationstest erfasst die erste RTR-Update-PDU und den Zeitpunkt, an dem die VRP-Tabelle die Änderung zeigt. Wo die Instrumentierung reicht, sollen erster und letzter installierter VRP sowie die Dauer des gesamten Stapels getrennt ausgewiesen werden. Ein weiterer Test beobachtet den Validierungsstatus betroffener BGP-Präfixe. Der Konvergenztest erfasst beste Pfade, Rücknahmen oder Ersetzungen und die endgültige Stabilität von RIB und FIB. „Validierung in Millisekunden“ kann ein korrektes Ergebnis für eine Station sein und trotzdem die falsche Zahl für die Planung des Datenpfads.

Auch die Last gehört in die Überschrift der Messung. Der Entwurf nennt beispielhafte VRP-Bestände von 50.000, 100.000, 500.000 und einer Million. Als mögliches BGP-Grundgerüst nennt er eine Million IPv4- und 250.000 IPv6-Routen; getrennte Adressfamilien sind möglich, wenn dies offengelegt wird. Diese Größen sind Laborparameter, weder Behauptungen über die aktuelle globale Tabelle noch Messergebnisse eines Produkts. Ein Bericht sollte tatsächliche ROA- und VRP-Zahlen, Abdeckung der BGP-Tabelle, Überlappungen, Präfixlängen und die Zahl der Statuswechsel nennen.

Anhang B prüft die Unterscheidung mit Daten. Auf einem BIRD-2.19.2/Linux-Prüfling mit anfangs 1.060.368 VRPs, 1.000 ausgewählten Präfixen und 1.230 VRP-Operationen ergaben zehn Läufe im Mittel 5.027,552 ms für den gesamten Weg und 4.813,556 ms nach der Installation. Rund 214 ms liegen in diesem Aufbau vor dem späten Startpunkt; der größte Teil der gemessenen Zeit folgt der Installation. Die Werte messen keinen anderen Router. Sie zeigen, warum Start, Last und Ende zusammen mit der Zahl veröffentlicht werden müssen.

Ein Stapel mit eng beieinanderliegenden Änderungen kann den Router anders belasten als weit verteilte Änderungen. Der Entwurf verlangt beide Muster. Vor dem Test werden RTR-, VRP- und BGP-Zustand synchronisiert und das Gerät aufgewärmt; Protokollierung, Echtzeittelemetrie und störende Hintergrundaufgaben sollen abgeschaltet oder gedrosselt werden. Das macht Läufe wiederholbar, begrenzt aber die Aussage. Ein Produktionsnetz mit laufender Beobachtung muss seine Einstellung gesondert testen, bevor es aus einer stillen Laborzahl Reserve streicht.

Der Entwurf liefert weder Sieger noch Ausfallstatistik. Er zwingt die Stoppuhr, ihre Startlinie zu zeigen. Für ROV-Kapazität zählt die Spanne vom relevanten RTR-Update bis zur stabilen FIB. Die Zeit nach Installation ist eine Diagnosegröße. Beide brauchen denselben Lastzettel.

ROV-Entwurf, Revision 00 · RFC 8210 · RFC 6811