Zusammenfassung

  • Revision 03 des GROW-Entwurfs zur Terminologie des globalen Routingbetriebs ist ausdrücklich eine beschreibende, nicht autoritative Momentaufnahme. Derselbe Ausdruck kann je nach Kontext verschiedene Bedeutungen tragen.
  • Ein cone kann eine rekursive Menge von Downstream-ASen bezeichnen und in anderem Zusammenhang die gemeinsame Menge der von ihnen originieren Präfixe. Ohne Mitgliedstyp, Konstruktionsmethode, Zeitpunkt und Beobachtungspunkt kann eine Automatisierung im falschen Universum korrekt rechnen.

Der Filterdienst erwartete Präfixe. Er erhielt eine Datei mit Zahlen wie 64500, 64501 und 64502, akzeptierte das Format und meldete eine vollständig verarbeitete Cone-Liste. Das vorgelagerte System hatte ASNs geliefert. Das nachgelagerte hatte die Zahlen als unvollständige Netzressourcen normalisiert. Kein Transportfehler, keine fehlende Zeile und kein Parserabsturz verriet, dass zwei verschiedene Mengen denselben Namen trugen.

Genau diese Art stiller Bedeutungsverschiebung macht Revision 03 von Currently Used Terminology in Global Routing Operations sichtbar. Tobias Fiebig und Wolfgang Tremmel reichten sie am 2. Oktober 2026 ein. Der Text sammelt Begriffe, die im gegenwärtigen globalen Routingbetrieb verwendet werden, erhebt aber keinen Anspruch, die autoritative Quelle korrekter Terminologie zu sein. Er beschreibt beobachtete Verwendung zu einem Zeitpunkt, erkennt Wandel an und lässt denselben Begriff in mehreren Abschnitten mit unterschiedlichen Beschreibungen erscheinen.

Datatracker führt das Dokument als aktiven Internet-Draft der GROW Working Group im IETF-Stream. Der angestrebte Status ist Informational, das Ablaufdatum der Revision der 5. April 2027. Es gibt derzeit weder RFC-Nummer noch verantwortlichen Area Director, Document Shepherd, Telechat oder abgeschlossenes Prozessergebnis. IANA-Aktionen werden nicht verlangt. Die Security Considerations erklären, dass der Text Terminologie beschreibt und keine Empfehlungen ausspricht, weshalb der Entwurf selbst keine Sicherheitsbetrachtungen habe.

Das grenzt die Behauptung des Dokuments ein. Es schützt nicht jedes System, das seine Wörter importiert. Ein Glossar führt keine Filterregel aus. Eine Pipeline, die einen beschreibenden Ausdruck als Maschinentyp, Berechtigung oder Aktionsauslöser verwendet, kann Verfügbarkeit und Erreichbarkeit sehr wohl verändern.

Eine Menge braucht einen Elementtyp

Der Entwurf beschreibt einen Cone als Menge direkt oder rekursiv nachgelagerter ASes. Je nach Kontext kann der Ausdruck auch die gemeinsame Menge der Präfixe umfassen, die diese ASes originieren. Die Verwandtschaft beider Konzepte erklärt den gemeinsamen Namen; sie macht die Mengen nicht austauschbar.

Eine ASN ist eine Identität im Routingkontext. Ein Präfix ist ein Adressraumintervall. Mitgliedschaft, Schnittmenge, Abdeckung und Differenz haben für beide Typen unterschiedliche Bedeutung. Die Frage „Gehört diese Ressource zum Cone?“ ist ohne Ressourcentyp nicht vollständig.

Auch die Abbildung zwischen beiden Mengen ist kein zeitloser Funktionsaufruf. Ein AS kann zu verschiedenen Zeiten andere Präfixe announcen. Mehrere ASes können Sichtbarkeit für dasselbe Präfix erzeugen. Ein Beobachter sieht möglicherweise nicht alle Pfade. Eine Origin-Beobachtung ist außerdem nicht automatisch ein Nachweis institutioneller Autorisierung.

Deshalb braucht eine Cone-Projektion mindestens den Elementtyp, die Beziehungsdefinition, die Rekursionsregel, die Quelle der Beziehungen, den Beobachtungspunkt, den Zeitpunkt und den Umgang mit Unbekanntem. Wird aus einem AS-Cone ein Prefix-Cone abgeleitet, muss diese Join-Operation mit ihren Belegen erhalten bleiben.

Ein API-Feld namens cone reicht nicht. downstream_as_set und observed_origin_prefix_set können in der Oberfläche gleich erklärt werden, müssen im Vertrag aber inkompatibel sein. Die sicherste Typprüfung ist jene, bei der eine Präfixoperation eine ASN-Menge tatsächlich ablehnt.

Revision 03 verbessert die Karte, nicht ihre Hoheitsgewalt

Gegenüber Revision 02 erweitert die neue Fassung Akronyme, Definitionen und Referenzen und korrigiert konkrete Formulierungen. BFD wird nicht länger so beschrieben, als stelle es fest, ob ein Nachbar „alive“ sei. Stattdessen prüft es die Erreichbarkeit eines konfigurierten Nachbarn und signalisiert den Verlust dieser Erreichbarkeit an Protokolle wie BGP.

Das ist eine wichtige Korrektur der Realitätsebene. Erreichbarkeit ist eine begrenzte Beobachtung. Leben, Dienstverfügbarkeit, Policy-Richtigkeit und Ende-zu-Ende-Zustellung sind viel breitere Aussagen. BFD Up kann neben einem ausgefallenen Dienst stehen; BFD Down benennt nicht von selbst die Ursache.

Die Überarbeitung präzisiert außerdem Kategorien optionaler BGP-Attribute und deren Weitergabe und fügt beziehungsweise verbessert Einträge zu BGP, EGP, IGP, EIGRP, IS-IS, OSPF und RIR. Als Lesehilfe für heutige Entwürfe wird das Dokument dadurch wertvoller.

Es wird dennoch kein Konformitätsprofil. Ein importierendes System muss Dokumentname und Revision speichern. Historische Felder dürfen nicht still nach der neuesten Definition umgedeutet werden. Ein altes cone könnte lokal eine andere Konstruktion bezeichnet haben. Wo sich der ursprüngliche Sinn nicht belegen lässt, ist „mehrdeutig“ der korrekte Zustand.

Eine semantische Migration sollte eine nachvollziehbare, umkehrbare Zuordnung erzeugen: alter Wert, vorgeschlagener Sinn, Indizien, Konfidenz und Prüfer. Das bloße Befüllen eines neuen Pflichtfeldes erzeugt keine historische Wahrheit.

Peer kann Beziehung oder Sitzung heißen

Auch peer trägt einen Typwechsel. Im Abschnitt über Nachbarbeziehungen bezeichnet das Wort zwei direkt verbundene ASes, die sich eigene und von Downstreams gelernte Routen anzeigen. Im Routingabschnitt kann es einfach einen BGP-Nachbarn meinen: zwei Speaker, die NLRI austauschen.

Der erste Sinn beschreibt eine Beziehung mit Exporterwartungen. Der zweite beschreibt eine Protokollsitzung. Kunde und Provider können BGP-Nachbarn sein, ohne Peering-Beziehung. Umgekehrt kann die Beziehung während einer Wartung fortbestehen, obwohl die Session nicht Established ist.

RFC 9234 macht Rollen durch BGP Roles im OPEN expliziter, um Route Leaks zu verhindern. Das ist ein gezielter Beleg, aber noch immer ein Konfigurations- und Verhandlungsbeleg. Vertrag, Operator-Erklärung, ausgehandelter Role, installierter Filter und beobachtete Exporte beantworten verschiedene Fragen.

RFC 4271 beschreibt einen lokalen Entscheidungsprozess. Die Routenauswahl eines Speakers beweist weder die Policy des Nachbarn noch den Paketpfad. Eine Datenbank, die Session-Zustand als Beziehungswahrheit speichert, lässt institutionelle Fakten bei jedem Reset oszillieren.

Wie beim Cone braucht der Maschinenvertrag einen stabilen Sinnbezeichner. as_route_exchange_relationship und bgp_neighbor_session dürfen denselben Anzeigenamen tragen, aber keine austauschbaren Werte sein.

Der Rand ist mehrdimensional

Network edge bezeichnet in einem Kontext die letzten Router unter Kontrolle eines Operators, die zu anderen Netzen verbinden. Provider Edge trägt üblicherweise eine funktionale Rolle in einem MPLS-Provider-Netz. Administrative Grenze und PE-Rolle können zusammenfallen, müssen es aber nicht.

Ein Inventar, das alle Geräte mit edge markiert, kann eine saubere MPLS-Konfiguration an den falschen Rand senden. Das Problem wird nicht durch ein längeres Etikett gelöst, sondern durch getrennte Prädikate: administrative Grenze, externer BGP-Rand, MPLS-PE, Service-Ingress und Telemetrie-Beobachtungspunkt.

Richtung und Gültigkeitszeit zählen ebenfalls. Ein Gerät kann für eine VRF PE und für einen anderen Dienst nur Transit oder Messpunkt sein. Ein geräteweites, zeitloses Label löscht diese Unterschiede.

Der gleiche Fehler kann einen Cone an der falschen Grenze anwenden. Ist unklar, ob das Feld Organisationen, ASes, Geräte oder Präfixe bezeichnet, vergrößert eine einzige Abstraktion gleichzeitig Zielmenge und Handlungsmacht.

Beobachtung und absichtliche Aktion teilen sich manchmal ein Wort

Blackholing kann allgemein still verworfene Pakete ohne ICMP-Rückmeldung beschreiben. Im Sicherheitskontext kann es das bewusste Announcen von Präfixen mit einer Community bezeichnen, damit Nachbarn Verkehr verwerfen. Das eine ist ein beobachtetes Symptom, das andere eine Kontrollhandlung.

Ein Incident-System, das aus einem Blackhole-Alarm automatisch eine Blackholing-Anweisung baut, verwechselt Diagnose mit Autorisierung. Für die Aktion braucht es Präfix, Community-Semantik beim Empfänger, Nachbarn, Zeitfenster, autorisierten Principal, Rücknahmebedingung und Ergebnisbeobachtung.

Operator ist ähnlich breit. Das Wort kann eine Person, eine Gruppe oder eine Organisationseinheit bezeichnen, die BGP-Speaker, Policy und administrative Änderungen verantwortet. „Operator approved“ identifiziert deshalb noch keinen Genehmiger, keine Rechtsgrundlage und keinen Umfang.

Verantwortlicher Bereich und autorisierender Principal gehören in getrennte Felder. Das erste leitet Arbeit weiter; das zweite trägt eine prüfbare Entscheidung. Eine Gruppenbezeichnung darf keine individuelle Berechtigung erfinden.

Eine entfernte Session beweist keinen verschwundenen Pfad

Der Entwurf beschreibt depeering als Entfernen von Sessions mit einem benachbarten AS. Ein erfolgreiches Konfigurationsrezept beweist, dass die bezeichneten Sessions entfernt wurden. Es beweist nicht, dass jede Route oder jeder Verkehr zu dieser Organisation verschwunden ist.

Eine zweite Interconnection, Transit, Default Route oder verbleibender FIB-Zustand kann Pakete weitertragen. Auch die institutionelle Beziehung kann fortbestehen, während Sessions aus Wartungsgründen fehlen. Konfigurationsbeleg, Control-Plane-Beobachtung und Data-Plane-Ergebnis müssen getrennt bleiben.

Für den Cone ist dies besonders relevant. Wenn ein AS-Set aus einer Relation entfernt wurde, heißt das nicht, dass sämtliche zugeordneten Präfixe an jedem Beobachtungspunkt verschwunden sind. Die abgeleitete Präfixmenge muss neu berechnet und als neue Projektion verifiziert werden.

Ein ehrlicher Status kann lauten: „Sessions entfernt; alternative Erreichbarkeit vorhanden; Beziehung unverändert; Traffic-Effekt teilweise bekannt.“ Ein einzelnes complete kann diese Gleichzeitigkeit nicht ausdrücken.

Vollständigkeit und Konvergenz brauchen Koordinaten

Full Table bezeichnet laut Entwurf eine Tabelle mit einer Route zu allen Präfixen der Global Routing Table und ohne Default Route. Um „alle“ zu prüfen, braucht man Adressfamilie, Speaker oder Collector, Import-Policy, Zeitpunkt und Referenzmenge.

IPv4 kann an einem Standort vollständig sein, während IPv6 fehlt. Zwei Beobachtungspunkte können wegen Policy und Propagation verschiedene Mengen sehen, ohne beschädigt zu sein. Eine reine Anzahl kann stimmen, obwohl wichtige Präfixe fehlen und andere, spezifischere Routen hinzukamen.

Control-Plane-Vollständigkeit beweist auch keine FIB-Installation. Ressourcenlimit, Rekursionsfehler, Filter oder Programmierverzug können eine ausgewählte Route vom Forwarding fernhalten. Eine FIB wiederum belegt keine Ende-zu-Ende-Zustellung.

Converged braucht ebenfalls Subjekt und Stopkriterium. Ein BGP-Speaker kann seine Auswahl beendet haben, während andere noch Updates verarbeiten, Hardware programmiert wird oder Datenpfade wechseln. Ein lokaler Wahrheitswert darf nicht als globaler Abschluss dienen.

Diese Koordinaten sind dieselben, die der Cone-Projektion fehlen. Ohne Beobachtungspunkt und Zeit ist weder die Menge der Origin-Präfixe noch ihre Erreichbarkeit reproduzierbar.

Ein Sicherheitslabel stellt keine Absicht fest

Der Entwurf beschreibt einen Route Hijack als Announcement einer Route durch ein AS, das dazu nicht autorisiert ist, und weist darauf hin, dass dies versehentlich durch Fehlkonfiguration oder absichtlich bösartig geschehen kann. Die technische Klassifikation entscheidet also nicht über Motivation.

RFC 7908 behandelt Route Leaks als Propagation über den beabsichtigten Umfang hinaus, entgegen erwarteter Policy. Um die Erwartung zu kennen, braucht die Untersuchung Beziehungs- und Konfigurationsbelege. Ein beobachteter AS_PATH zeigt die Propagation, rekonstruiert aber keine Genehmigungskette.

RPKI liefert einen engeren Nachweis. RFC 6480 beschreibt die Ressourcenzertifikatsarchitektur, RFC 9582 ROAs, mit denen ein Halter einem AS die Originierung von Präfixen erlaubt. Ein gültiger Origin beweist keine korrekte Pfadpolicy, globale Erreichbarkeit oder Zustellung. Invalid oder NotFound sind ihrerseits Eingaben lokaler Policy, keine selbstvollstreckenden Universalurteile.

Auch hier muss der Datentyp stimmen: Validierungsstatus, beobachtetes Announcement, behauptete Beziehung, kausale Hypothese und Absicht sind unterschiedliche Objekte. Wer sie in incident_type presst, macht aus schmaler Evidenz breite Gewissheit.

Der minimale semantische Umschlag

Bevor ein beschreibender Begriff eine wirkungsvolle Aktion steuert, sollte der Datensatz mindestens enthalten: Originalterm; Vokabular und Revision; stabile Sinn-ID; Kontext; Subjekte und Richtung; Beobachtungspunkt und Zeit; Quelle oder Beleg; angeforderte Aktion und autorisierter Principal; Unsicherheit und konkurrierende Deutungen.

Für Mengen kommen Elementtyp, Konstruktionsmethode und Ableitung hinzu. Für Zustände braucht es Geltungsbereich und Stopkriterium. Für Aktionen sind Ziel, Zeitfenster, Rücknahme und Erfolgsbeobachtung erforderlich. Diese Ergänzungen sind kleiner als eine universelle Ontologie, aber groß genug, um gefährliche Typfehler zu stoppen.

Minimum Initial Specification bedeutet hier: nicht jedes Routingwort abschließend definieren, sondern die minimale Hülle verbindlich machen. Running-Code Primacy bedeutet: inkompatible Übergaben wirklich testen. ASN-Cone an Prefix-Funktion, Session-Peer an Beziehungspolicy, administrative Edge an PE-Template, lokales Converged an globalen Abschluss — jeder Fall muss scheitern oder unbekannt bleiben.

Legacy-Felder mit nacktem Text dürfen nicht still hochgestuft werden. Eine Migration kann einen Sinn vorschlagen und Belege nennen. Wenn der historische Sinn nicht wiederherstellbar ist, bleibt er unbekannt. Schemavollständigkeit ist kein Ersatz für Wahrheit.

Der begrenzte Anspruch macht das Glossar brauchbar

Revision 03 ist wertvoll, weil sie die Vielfalt realer Sprache nicht unter einem künstlichen Standard versteckt. Sie sammelt, verbessert und kontextualisiert. Erfahrene Operatoren sehen dadurch Annahmen, die sie sonst automatisch ergänzen.

Jeder Verbraucher muss seine eigene Verantwortung übernehmen. Inventare definieren Typen. Policy Engines verlangen Prädikate. Agenten erhalten begrenzte Fähigkeiten. Incident-Prozesse trennen Beobachtung, Ursache, Absicht, Entscheidung und Ergebnis. Keines dieser Systeme darf dem Glossar die Entscheidung zuschieben.

In Heng Lus Realitätsschichten ist ein Begriff symbolische Koordination; Beziehung und Autorisierung sind institutionelle Objekte; Konfiguration und Sitzung sind ausführbarer Zustand; Propagation und Paketlieferung sind beobachtete Wirklichkeit. Ein gemeinsamer Name verbindet diese Schichten nur im Gespräch, nicht als Beweis.

Die Eingabedatei des Anfangs war nicht leer und nicht beschädigt. Sie enthielt nur nicht den Typ, den das nächste System brauchte. Der richtige Fix ist deshalb keine bessere Vermutung. Er ist ein Vertrag, der eine ASN-Menge niemals als Präfixmenge passieren lässt und jede notwendige Umwandlung als zeitgebundene, belegte Projektion sichtbar macht.

Sources