Zusammenfassung

  • RFC 3139 zeigte am Beispiel eines „Gold-Service“, dass eine netzweite Vorgabe erst zusammen mit Topologie, Geräteeigenschaften und Betriebsdaten in lokale Konfigurationen überführt werden konnte.
  • Im Netz konnten mehrere Übersetzer zusammenarbeiten; an einem bestimmten Gerät durfte zu einem Zeitpunkt jedoch nur einer handeln. Richtlinienbeschluss, Übersetzung, koordinierte Ausbringung, Gerätebestätigung und tatsächliche Verkehrsbehandlung blieben getrennte Nachweise.

Das Adjektiv war ein Auftrag, kein Gerätebefehl

Für eine Vertriebsvereinbarung genügt der Satz, bestimmte Kunden erhielten „Gold“. Ein Router kennt aber keine Vertragsfarbe. Er braucht Klassifikatoren, Warteschlangen, Grenzwerte, Zeitsteuerung und eine genaue Zuordnung zu Schnittstellen. Schon ein Wechsel des Pfades kann verändern, auf welchen Geräten welche Teile der Zusage umgesetzt werden müssen.

RFC 3139 nahm diese Lücke als Ausgangspunkt. Derselbe gewünschte Dienst konnte bei verschiedenen Herstellern andere Parameter und auf einem einzelnen Gerät zahlreiche Befehle verlangen. Die Abstraktion war also nicht wertlos. Sie war gerade deshalb nützlich, weil sie die lokalen Unterschiede zunächst verbarg. Gefährlich wurde sie erst, wenn das Verbergen mit bereits erfolgter Umsetzung verwechselt wurde.

Der im Juni 2001 als Informational veröffentlichte Text standardisierte kein Protokoll. Er entstand aus der Sorge, dass einzelne IETF-Arbeitsbereiche jeweils technologiebezogene Konfigurationslösungen entwickelten. Bei einem Treffen 1999 wurden unter anderem COPS/PIB- und SNMP/MIB-Ansätze verglichen, ohne in mehreren Fragen Einigkeit zu erzielen. Das Designteam formulierte daraufhin Anforderungen an eine integrierte Lösung, statt einen Sieger zu erklären.

Deshalb beschreibt das normative Vokabular des Dokuments notwendige Eigenschaften einer solchen Lösung. Es beweist weder, dass ein vorhandenes System sie erfüllte, noch macht es RFC 3139 zu einem Internet Standard. Auch die zeitlich benachbarten RFCs zu COPS, COPS-PR und dem Policy Core Information Model sind Kontext, keine Implementierungsquittung.

Zwischen Entscheidung und Router lagen drei Darstellungen

Das Dokument unterschied hochrangige Konfigurationsdaten, netzweite Konfiguration und gerätelokale Konfiguration. Auf der obersten Ebene standen Modell und erwartetes Verhalten. Die netzweite Ebene war nicht an ein einzelnes Gerät gebunden. Erst die lokale Ebene enthielt die feinste, für genau ein Gerät bestimmte Form.

Ein configuration-data translator verband diese Ebenen. Er konnte ein Mensch sein, zentral als Software laufen, in einem Zwischensystem sitzen oder nahe am Gerät arbeiten. Der RFC legte die Funktion fest, nicht ihren physischen Standort. Ein zentraler Server war ebenso wenig vorgeschrieben wie ein dauerhaft einheitlicher Hersteller.

Für eine korrekte Übersetzung genügte der Richtlinientext nicht. Die Abbildungen des RFC führten Topologie sowie Status-, Leistungs- und Überwachungsinformationen in den Prozess. Ein Übersetzer kann eine intern schlüssige lokale Konfiguration erzeugen und trotzdem falsch liegen, wenn er einen veralteten Pfad, eine nicht vorhandene Warteschlange oder eine falsche Redundanzannahme verwendet.

Fehlten Informationen, die für eine fehlerfreie Umwandlung benötigt wurden, sollte das System dies erkennen und entsprechend handeln. Der Text schrieb nicht vor, ob es stoppen, warten, einen engen sicheren Umfang wählen oder menschliche Prüfung verlangen musste. Er zog eine wichtigere Grenze: Unwissen durfte nicht lautlos wie gesicherte Übersetzung aussehen.

Damit entstand eine Kette von Nachweisen. Zuerst musste die Richtlinie identifiziert und beschlossen sein. Danach brauchten Topologie- und Fähigkeitsstand eine Identität. Aus ihnen entstand eine netzweite Projektion, daraus eine gerätespezifische Auswahl und schließlich ein lokaler Kandidat. Erst Annahme und Rückmeldung des Geräts belegten weitere Schritte. Keine frühe Stufe durfte sich die Beweiskraft der späteren leihen.

Mehrere Übersetzer waren erlaubt, konkurrierende Autoren nicht

Ein großes Netz konnte die gesamte Arbeit nicht einem einzigen Menschen überlassen. RFC 3139 erlaubte daher mehrere Übersetzer, die gemeinsam oder hintereinander auf einer Gerätemenge arbeiteten. Eine Stufe konnte Geschäftsabsicht in ein Netzmodell überführen, eine weitere ein Technologieprofil wählen, eine dritte konkrete Werte erzeugen.

Am Gerät setzte der Text jedoch eine klare Bedingung: Zu einem bestimmten Zeitpunkt durfte nur ein configuration-data translator auf einem bestimmten Gerät operieren. Eine Pipeline durfte mehrere Stufen haben. Die letzte Schreibgrenze durfte nicht gleichzeitig von unabhängigen Autoren besetzt sein.

Das war noch kein ausgearbeiteter Sperrmechanismus. Der RFC definierte weder Wahlverfahren noch Lease, fencing oder Wiederanlauf nach einem Absturz. Er benannte eine Invariante. Zwei Controller können aus unterschiedlichen Richtlinienrevisionen oder Topologiesichten jeweils plausible Kandidaten ableiten. Werden ihre Befehle vermischt, entsteht womöglich ein Zustand, den keiner der beiden beabsichtigt hat.

Ein Prozess könnte den Klassifikator eines neuen Gold-Profils installieren, während ein anderer den Scheduler eines alten Profils wiederherstellt. Das Gerät bestätigt beide Befehle. Am Ende stammen Klassifikator, Warteschlange und Ablaufzeit aus verschiedenen Generationen. Zwei erfolgreiche Antworten sind dann zwei Transportnachweise, aber kein Nachweis einer kohärenten Richtlinie.

Die zusätzliche Forderung, Fehlkonfiguration durch konkurrierenden gemeinsamen Schreibzugriff zu beseitigen, zielte auf denselben Bruch. Eine belastbare Quittung braucht den Schreiber, die Richtlinienrevision, den Eingabe-Snapshot, den Gerätesatz und das Ausschlussintervall. „Letzter Schreibzugriff gewinnt“ ordnet Speicheroperationen; er erklärt nicht, warum der resultierende Zustand richtig sein sollte.

Der gefährlichste Zwischenzustand lag oft zwischen Geräten

Netzverhalten entsteht selten auf nur einem Router. RFC 3139 verlangte deshalb, vollständige oder partielle Konfiguration bei Bedarf gleichzeitig oder synchronisiert hinzufügen, ändern, löschen, auslesen und wiederherstellen zu können. Die Einschränkung „bei Bedarf“ ist wesentlich: Nicht jede Teiländerung ist falsch, und nicht jedes Update braucht eine globale Barriere.

Entscheidend ist die Abhängigkeit. Ein passiver Klassifikator kann gefahrlos vor einer Route angelegt werden. Dieselbe Route kann ohne den vorgesehenen Schutz Verkehr freigeben. Eine Ingress-Markierung kann aktiv werden, bevor der Kern die Klasse behandelt. Zwei lokal korrekte Geräte können während des Übergangs gemeinsam ein falsches Netz bilden.

Der RFC forderte Fehlererkennung, auch für datenspezifische Fehler, sowie Wiederherstellung nach Fehlern. Unangemessen partielle Konfiguration sollte verhindert werden, wenn der Zusammenhang dies verlangte. Daraus folgt aber kein garantiert atomarer verteilter Commit. Der Text enthielt kein universelles prepare/commit, keine allgemeine Rollback-Semantik und keine Definition, nach der jeder partielle Zustand unzulässig wäre.

Eine Betriebsstelle muss daher sichere Teilmengen, Reihenfolge und Abschlusskriterien vorher kennen. „Batch abgeschlossen“ ist die Aussage des Orchestrators. Geräteantworten zeigen lokale Annahme oder Ablehnung. Ein Zustands-Snapshot zeigt gespeicherte oder angewandte Werte. Messungen zeigen, welchen Weg Pakete tatsächlich nahmen. Diese Belege können einander stützen, aber nicht ersetzen.

Schnelle Umschaltung verlangte langsame Vorbereitung

RFC 3139 verlangte außerdem, mehrere gerätelokale Konfigurationen vorhalten zu können. Bei einer Störung sollte nicht erst eine große Änderung an viele Geräte übertragen werden müssen. Die spätere schnelle Entscheidung wurde durch frühere Vorbereitung ermöglicht.

Ein vorbereiteter Kandidat ist jedoch noch nicht aktiv. Seine Aktivierung beweist nicht, dass er zu diesem Zeitpunkt noch geeignet ist. Seit der Vorbereitung können sich Topologie, Kundenmenge, Gerätefähigkeit oder Richtlinie geändert haben. Eine gestern richtige Reserve kann heute den falschen Fehlerbereich teilen oder auf nicht mehr vorhandene Ressourcen zeigen.

Auch redundante Konfigurationsplattformen und Netzelemente gehörten zu den Anforderungen. Redundanz macht die Autorenfrage dringlicher: Welches System darf schreiben? Welchen aktuellen Stand hat sein Ersatz übernommen? Wie wird verhindert, dass der ehemalige Primärcontroller nach seiner Rückkehr ebenfalls handelt? Zwei lebende Instanzen sind noch keine sichere Kontinuität.

Deshalb brauchen vorbereitete Alternativen eine Herkunft: Richtlinienversion, Inventar, Topologieannahmen, Erstellungszeit, Gültigkeitsfenster und Auslösebedingung. Ohne diese Angaben ist „vorkonfiguriert“ nur ein Speicherzustand, keine freigegebene Handlungsoption.

Rückmeldung schloss den Gerätekreis, nicht den Dienstnachweis

Das Konfigurationssystem sollte Bestätigungen, Netzzustand, Überwachungsdaten und bestimmte Ereignisse zurückerhalten. Ohne Rückmeldung blieb Übersetzung eine Einbahnstraße. Mit Rückmeldung konnte das System Absicht und gemeldeten Zustand vergleichen.

Doch das Wort Bestätigung ist ungenau. Hat das Gerät die Nachricht geparst, in einen Kandidaten geschrieben, validiert, committed, aktiviert oder einen Neustart überstanden? Hat die Weiterleitungsebene den Wert übernommen? Verschiedene Plattformen können „Erfolg“ an sehr unterschiedlichen Stellen melden.

RFC 3139 verlangte, lokale Konfiguration sowie Status und Monitoring im Kontext der netzweiten Konfiguration interpretieren zu können. Das ist mehr als Datensammlung. Eine lokale Warteschlange kann exakt dem erzeugten Befehl entsprechen und dennoch nicht mehr zur Richtlinie passen, weil sich der Pfad geändert hat. Umgekehrt kann eine lokale Abweichung die einzig korrekte Ausdrucksform einer gemeinsamen Absicht sein.

Selbst vollständige Geräterückmeldung beweist keinen End-to-End-Dienst. Verkehr kann einen anderen Pfad nehmen. Ein Filter kann die erwartete Kundengruppe verfehlen. Alle Router können das Gold-Profil melden, während reale Pakete nie in dieser Klasse ankommen. „Installiert“ und „erfahren“ sind verschiedene Beobachtungen.

Konfiguration besaß eine Zeitdimension

Der RFC forderte Wirksamkeits- und Ablaufzeiten. Manche Einträge mussten verfallen können, andere durften ausdrücklich ohne Ablauf markiert sein. Damit wurde Zeit zu einem Teil der Autorität.

Eine zukünftige Regel kann gültig gespeichert, aber noch inaktiv sein. Eine abgelaufene Regel kann weiterhin auf dem Gerät liegen, ohne noch angewendet werden zu dürfen. Controller- und Geräteuhr können abweichen. Das Wiederherstellen eines alten Snapshots kann eine Ausnahme erneut beleben, deren ursprüngliche Laufzeit längst endete.

Eine aussagekräftige Quittung enthält deshalb Erstellungszeit, geplante Wirksamkeit, Ablaufsemantik, verwendete Zeitbasis, installierten Zustand und beobachtetes Durchsetzungsintervall. „In der Konfiguration vorhanden“ beantwortet nicht die Frage, ob der Eintrag jetzt den Verkehr bestimmt.

Dynamische Bereitstellung nach Geräte- oder Netzereignissen stellt dieselbe Frage unter Zeitdruck. Welches Ereignis löste die Änderung aus? War die Richtlinie noch gültig? Handelte ein zweiter Übersetzer bereits? Ist die Reparaturkonfiguration abgelaufen? Geschwindigkeit ohne Identität und Zeit kann einen Regelkreis in eine Schwingung verwandeln.

Sicherheit bedeutete auch rekonstruierbare Ursache

RFC 3139 verlangte Zugriffskontrolle, Authentisierung, Integrität, Schutz vor Replay und gegebenenfalls Vertraulichkeit. Kontrolle auf Hostebene war das Minimum; Benutzer- oder Rollenrechte sollten feinere Privilegien ermöglichen. Änderungen sollten bis zu Host und Benutzer zurückverfolgbar sein.

Diese Eigenschaften waren keine Beigabe. Ein syntaktisch richtiger Wert ist eine ungültige Zustandsänderung, wenn ein nicht autorisierter Prozess ihn schrieb. Eine ehemals legitime, signierte Nachricht kann beim Replay veraltete Topologieannahmen oder ausgelaufene Ausnahmen zurückbringen. Authentisierung sagt, wer gesendet hat; Integrität, ob die Nachricht verändert wurde; Frische und Berechtigung, ob dieser Absender diese Änderung jetzt ausführen durfte.

Rückverfolgbarkeit hilft auch bei der Wiederherstellung. Wenn Geräte auseinanderlaufen, reicht ein Diff nicht. Benötigt wird die Kausalkette: Welche Richtlinie änderte sich? Welche netzweite Projektion wurde erzeugt? Welcher Übersetzer besaß welches Gerät? Welcher lokale Kandidat entstand? Welche Befehle wurden angenommen? Welche Rückmeldung lag vor, bevor der nächste Autor begann?

Spätere Architekturen schärften die Grenze, erfanden sie aber nicht rückwirkend

Der IAB Network Management Workshop von 2002, dokumentiert in RFC 3535, hielt den operativen Druck auf bessere Konfigurationsverfahren fest. NETCONF definierte später Operationen über Datastores, Sperren, Validierung, Commit und Fehlerbehandlung. Die Network Management Datastore Architecture unterschied später beabsichtigte Konfiguration, angewandte Konfiguration und operativen Zustand.

Diese späteren Spezifikationen zeigen, dass die in RFC 3139 sichtbaren Grenzen wiederkehrten. Sie dürfen nicht rückwärts als Beleg gelesen werden, dass der Anforderungstext von 2001 bereits NETCONF-Locks, candidate-Datastores oder NMDA-Reconciliation implementiert hätte.

Die bleibende Einsicht ist einfacher und strenger: Eine global verständliche Richtlinie kann lokal nicht ausführbar sein. Ein Übersetzer kann gültige Befehle aus veralteten Fakten erzeugen. Ein Gerät kann sie akzeptieren, ohne den versprochenen Dienst zu liefern. RFC 3139 ließ das Wort „Gold“ diese Übergänge nicht überspringen.