Zusammenfassung

  • Das externe OSPF-Route-Tag aus RFC 1403 beschrieb Erzeugungsart, Vollständigkeit und eine Längenklasse des Pfads; es enthielt keinen vollständigen AS_PATH.
  • Manuelle Tags blieben undurchsichtige lokale Werte. Automatische Tags unterschieden lediglich Pfadlänge null, eins oder größer als eins.
  • War ein Pfad abgeschnitten oder nur in einem getrennten BGP-Datensatz vollständig, entzog die Informationslücke der OSPF-Projektion die Befugnis zum Re-Export.

Der Übersetzer an der Grenze hatte ein Gedächtnisproblem

BGP und OSPF beschrieben Erreichbarkeit in verschiedenen Modellen. Außen führte BGP eine Interdomain-Historie mit; innen berechnete OSPF Kosten und nächste Schritte. Ein ASBR konnte einen BGP-Datensatz in OSPF importieren. Ein anderer konnte später dieselbe interne Route finden und sie wieder nach außen tragen wollen.

RFC 1403 teilte das 32-Bit-Tag in ein Automatic-Bit, ein Completeness-Bit, zwei PathLength-Bits, zwölf frei verwendbare Bits und sechzehn Bits für eine AS-Nummer. PathLength war nur eine Klasse. Das Tag sagte etwas über den Zustand des Wissens, nicht über die ganze Sequenz.

Stand Automatic auf null, waren die übrigen 31 Bits lokales LocalInfo. Aus Kompatibilitätsgründen war das der Standard. Der RFC verbot, daraus Eigenschaften der Route abzuleiten. Erst ein automatisch erzeugtes Tag aktivierte die gemeinsame Grammatik.

Automatic bedeutete dabei nicht authentisch. Sicherheitsfragen behandelte der Text ausdrücklich nicht. Das Bit erklärte die Lesart, nicht die Vertrauenswürdigkeit von Router, Eingabe oder Konfiguration.

Fehlende Evidenz konnte verloren oder anderswo verwahrt sein

Bei einem lokalen Pfad oder genau einem Nachbar-AS konnte die grobe Klasse für eine begrenzte Abbildung reichen. Eine längere Folge passte nicht in das Feld.

War diese Folge bereits abgeschnitten, konnte das Tag nur „unvollständig und länger“ melden. Ein anderer ASBR durfte die Route nicht wieder nach BGP exportieren. Es gab keine normative Vermutung, die aus fehlenden Stationen eine glaubhafte Historie machte.

War der vollständige Pfad noch vorhanden, lag er außerhalb der OSPF-Projektion. BGP sollte ihn zwischen den Grenzroutern desselben AS verteilen. Ein ASBR musste auf dieses interne BGP-Update warten, bevor er extern annoncierte. RFC 1403 nannte diesen Fall „out of band“: Nicht ein zweiter Datenkanal, sondern ein zweiter Routingdatensatz bewahrte, was das Tag nicht tragen konnte.

Im ersten Fall war die Evidenz zerstört, im zweiten hatte sie eine andere Verwahrung. In beiden durfte die Zusammenfassung die Quelle nicht ersetzen.

Ein Eintrag war noch keine Veröffentlichungsbefugnis

OSPF-Routen wurden standardmäßig nicht nach BGP exportiert. Externe OSPF-Routen brauchten explizite Konfiguration. BGP-Routen gelangten ebenfalls nicht ohne Auswahl nach OSPF; auch eine Default-Route durfte nicht ungefragt entstehen.

Lernen, importieren und annoncieren waren getrennte Handlungen. Tabellenpräsenz belegte weder erhaltene Provenienz noch Exportgenehmigung.

Auch Metriken widerstanden einer Scheingleichheit. OSPF cost und BGP-3 INTER-AS METRIC hatten andere Breite und Funktion. RFC 1403 ließ das optionale BGP-Attribut standardmäßig weg. Eine mathematische Abbildung übertrug keine Bedeutung.

BGP Identifier und OSPF router ID sollten auf einem Gerät übereinstimmen. Bei mehreren importierenden ASBRs konnte ein dritter so den tatsächlich verwendeten internen Ausgang mit dessen vollständigem BGP-Pfad verbinden.

RFC 1745 aktualisierte 1994 das Modell für BGP-4, IDRP, variable Präfixe, Pfadmengen, MULTI_EXIT_DISC und LOCAL_PREF. Gleichwertige Ausgänge konnten eine Zusammenführung in ein Set verlangen. Die Grenze blieb: Ein abgeschnittener Pfad durfte nie re-exportiert werden; ein vollständiger längerer Pfad musste erst über BGP/IDRP eintreffen.

Die Abbildung von OSPF Forwarding Address auf BGP NEXT_HOP konnte einen unnötigen Hop vermeiden. Sie belegte keine tatsächlich weitergeleiteten Pakete, entfernte Antwort oder Anwendungswirkung. Quellenroute, Import, Tag-Provenienz, Vollständigkeit, Exportpolicy, Vollpfad, Ankündigung, Forwarding und Ergebnis bleiben eigene Realitätsschichten.

RFC 1403 und RFC 1745 sind heute Historic. Sie beweisen keine gegenwärtige Implementierung oder einen Vorfall. Ihr bleibender Satz lautet: Wer Unvollständigkeit deklariert, muss zugleich die Befugnisse zurücknehmen, die das fehlende Detail voraussetzen.

Quellen

Diese Quellen belegen Dokumentstatus, Feldsemantik und spezifizierte Pflichten, nicht heutige Verbreitung, Authentizität, erfolgreiches Forwarding oder Nutzerwirkung.