Zusammenfassung

  • Die im RFC 1482 genannten 33 Prozent waren eine Modellrechnung über potenziell entfallende Ankündigungen, keine Vorher-nachher-Messung an produktiven Routern.
  • Das vorgeschlagene Register trennte Home AS, weiterankündigendes AS und jeweilige Nachbarn. Bei Proxy-Aggregation konnte sogar ein einzelnes Komponentenpräfix eine größere Ankündigung auslösen, ohne die Erreichbarkeit des gesamten Blocks zu belegen.

Eine präzise Zahl mit bewusst begrenzter Aussage

Der RFC 1482 nennt 12.348 Ankündigungen als Ausgangsmenge und 4.135 als möglicherweise vermeidbar. Daraus ergeben sich 33 Prozent. Der Text bezeichnet das Ergebnis zugleich als optimistische Schätzung, die mit einem pessimistischen Algorithmus gewonnen wurde, und hält fest, dass die wirkliche Einsparung anders ausfallen könne.

Diese Qualifikation gehört zur Zahl. Die Rechnung ordnete vorhandene Informationen nach möglicher Zusammenfassung. Sie maß nicht zwei Zustände derselben Router vor und nach einem dokumentierten Rollout. Sie bewies weder, dass jedes identifizierte Aggregat registriert wurde, noch dass die erzeugten Konfigurationen liefen oder alle Nachbarn die kompaktere Sicht erhielten.

Auch der Zeithorizont war geteilt. Eine unmittelbare Verringerung von Einträgen war etwas anderes als langsameres künftiges Tabellenwachstum. Und beides war etwas anderes als die Erschöpfung des Adressraums. Eine Prozentzahl durfte nicht für alle drei Probleme zugleich sprechen.

Der Eintrag des RFC Editor führt das Dokument heute als Historic. 1993 erklärte der Text die Implementierung für angelaufen, ließ aber Planung, Diskussion, Fehlersuche, Stabilität und Entscheidungsalgorithmen offen. Ein laufendes Vorhaben ist noch kein Messprotokoll.

Die alte Datenbank speicherte erwartete Quellen

Die Policy-Based Routing Database der NSFNET verband Netze mit AS-Nummern, von denen Ankündigungen erwartet wurden. Im Beispiel für Netz 35 erscheinen primäre, sekundäre und weitere Quellen.

Das war eine Zulassungsregel. Ein eingetragenes AS hatte nicht damit bewiesen, dass es zu einem bestimmten Zeitpunkt sendete. Ein Router konnte eine erlaubte Aktualisierung nicht empfangen, nach Empfang verwerfen oder nach Auswahl nicht in die Weiterleitung übernehmen.

Für die Gegenrichtung gab es nachbarnbezogene announcetoAS-Anweisungen. Sie konnten unbeschränkt oder restriktiv sein, bestimmte Netze einschließen, andere ausschließen oder alle Ankündigungen an ein AS unterbinden. Somit erzeugte das Backbone keine einheitliche Außenansicht. Jeder Nachbar erhielt eine politische Projektion.

Midlevel-Netze reichten ihre Regeln bei Merit ein; sie flossen in Konfigurationsdateien der ANSnet-Router ein. Zwischen Eingabe und Verhalten lagen Datenbank, Bericht, Generator, Parser und laufender Prozess. RFC 1482 verlangte Änderungen an all diesen Werkzeugen und verwies auf den konzeptionellen Wechsel von rcp_routed zu GateD.

Direkt empfangen und stellvertretend erzeugt

Ein CIDR-fähiges Regionalnetz konnte ein Aggregat direkt ankündigen. Die Datenbank nannte dann die ASs, von denen das Backbone diese Ankündigung erwarten sollte.

Für ein Regionalnetz ohne diese Fähigkeit sah der RFC Proxy-Aggregation vor. Ein GateD-Beispiel verband drei Komponentenpräfixe mit einer Oder-Bedingung. Sobald eines von ihnen gehört wurde, konnte das Backbone das größere Präfix speichern und weitergeben, als hätte es das Aggregat selbst empfangen.

Die konkrete Syntax war noch beispielhaft. Die Beweisgrenze war bereits klar: Ein Teil konnte eine Aussage über das Ganze auslösen. Blieb die erste Komponente aktiv, während die zweite zurückgezogen und die dritte nie installiert wurde, konnte das deckende Präfix weiterhin sichtbar sein.

RFC 1482 erwähnte Löcher innerhalb eines Aggregats. Verkehr zu einem solchen Loch konnte erst ein AS durchqueren und danach verworfen werden. Die größere Route wies eine Richtung, garantierte aber keine Zustellung zu jeder eingeschlossenen Adresse.

Home AS und unmittelbarer Absender waren verschiedene Rollen

Das vorgeschlagene Aggregate Registry enthielt Präfix, Home AS, Announcing AS, Neighbor-AS-Liste und Kontakte. Das Home AS war der Provider, der die Erreichbarkeit der Komponenten zunächst zusammenfasste. Ein Announcing AS gab dasselbe Aggregat an eigene Nachbarn weiter.

Im Arbeitsbeispiel ist AS 100 das Home AS. Dasselbe Präfix erscheint zusätzlich mit AS 690, AS 200 und AS 201 sowie unterschiedlichen Nachbargruppen. Mehrere Zeilen bewahrten die beabsichtigten Weitergabestufen.

Ein Beobachter hinter AS 200 konnte die Route von AS 200 erhalten, ohne dass AS 200 dadurch zum Home AS wurde. Umgekehrt bedeutete Home AS 100 nicht, dass jeder Beobachter direkt mit AS 100 sprach. Ursprung der Aggregation, Transit und Empfänger waren getrennte Tatsachen.

Spätere Spezifikationen helfen bei der Einordnung. RFC 1771 beschreibt BGP-4-Attribute und AS-Pfade. RFC 1786 formuliert eine reichere Sprache für Routing-Policy-Register. Keiner der Texte beweist rückwirkend, dass jede 1993 vorgeschlagene Registerzeile umgesetzt wurde.

Das Register koordinierte Absicht

Aggregatinformationen sollten elektronisch auch über die NSFNET-Gemeinschaft hinaus abrufbar sein. Änderungen konnten per E-Mail oder Online-Registrierungswerkzeug eintreffen. Das erleichterte Koordination, machte das Register aber nicht zur Live-Messung.

Der RFC definierte keine authentisierte Veröffentlichungskette, keinen Beobachtungszeitpunkt für Updates, keine Rückzugsquittung und keinen automatischen Abgleich mit empfangenen, ausgewählten und weitergeleiteten Routen. Sicherheitsfragen wurden ausdrücklich nicht behandelt.

Eine korrekte Registerzeile sagte, wer ein Präfix welchen Nachbarn ankündigen wollte. Ob der erzeugte Stand installiert war, ob ein Update einging, ob der Router es auswählte und ob Pakete ankamen, musste an anderen Stellen geprüft werden.

Für Nachbarn wurde das Aggregat nicht wieder zerlegt

Die erste NSFNET-Umsetzung sollte Aggregate beim Export nicht in spezifischere Routen zurückverwandeln. Ein Nachbar mit Bedarf an vollständiger Information musste ein CIDR-fähiges Protokoll nutzen. Ein Default-Routing-Nachbar konnte Ziele unter dem Aggregat erreichen, ohne alle Komponenten zu kennen.

Die sichtbare Granularität war damit Teil des Austauschs. Eine grobe Sicht bewies nicht, dass dem Exporteur Details fehlten. Interne Details bewiesen auch nicht, dass jeder Nachbar sie erhalten sollte.

RFC 1338 und RFC 1519 erläutern den architektonischen Druck hinter klassenloser Zuweisung und Aggregation. Sie erklären, weshalb Kompression nötig war. Sie machen ein einzelnes Aggregat nicht zum vollständigen Nachweis aller darunterliegenden Netze.

Skalierung verkürzte die Tabelle, nicht die Beweiskette

Das Aggregat war erfolgreich, wenn viele mögliche Ziele mit weniger öffentlichen Einträgen erreichbar blieben. Gerade dadurch trug die sichtbare Route weniger Herkunftsinformation.

Eine belastbare Untersuchung muss Komponenten und Grenze, Home AS, jedes Transit-AS, jeden Nachbarn, Registerversion, erzeugte und installierte Konfiguration, empfangenes Update, Auswahl, Export, Forwarding und Zielergebnis getrennt erhalten.

Bleibt nur das Endpräfix, überlebt die kompakte Zahl, aber ihre Ursache verschwindet. Dann lässt sich weder die 33-Prozent-Prognose nachmessen noch feststellen, welche Komponente eine Proxy-Regel auslöste oder welches Loch hinter der Zusammenfassung lag. Der eigentliche Preis der kleineren Tabelle war deshalb eine längere Provenienzkette.

Quellen