Zusammenfassung

  • RFC 9104 weist dem Link-Attribute-TLV für die Extended Administrative Group den Typ 1173 zu. Gültige Länge und unveränderte Bits belegen den Transport, nicht ihre lokale Deutung oder eine Pfadauswahl.
  • Eine belastbare Beweiskette trennt IGP-Quelle, BGP-LS-Projektion, AG/EAG-Konsistenz, Consumer-Wörterbuch, Policy-Version, Berechnung, Installation und Paketbeobachtung.

Ein gültiges Feld erreicht eine noch unentschiedene Maschine

Ein Consumer erhält hypothetisch ein Link NLRI mit einem Attribut, das TLV 1173 enthält. Der Wert ist acht Oktette lang, der Parser liest zwei 32-Bit-Wörter und die Sitzung bleibt stabil. Die Länge ist durch vier teilbar; syntaktisch liegt kein Fehler vor.

Die Aussage „der Controller kennt nun die Link-Farben“ verschmilzt mehrere Vorgänge. Der Producer hat ein Bitfeld transportiert. Der Consumer hat eine Datenstruktur angenommen. Ein lokales Wörterbuch kann Positionen mit betrieblicher Bedeutung verbinden. Eine Policy kann diese Bedeutung nutzen. Ein Rechenkern kann Kandidaten bestimmen, ein Pfad kann installiert werden und Pakete können ihm schließlich folgen.

RFC 9104 wurde im August 2021 als Standards-Track-RFC veröffentlicht. Sie definiert, wie BGP Link-State die Extended Administrative Group, kurz EAG, eines Links repräsentiert. Link Attribute TLV 1173 enthält eine oder mehrere 32-Bit-Bitmasken. Length zählt die Oktette des Values und muss ein Vielfaches von vier sein.

Dieses Format bewahrt das Bitfeld. Es enthält weder ein betriebliches Vokabular noch Policy-Prioritäten, einen Rechenauftrag, einen gewählten Pfad oder eine Bestätigung aus der Forwarding Plane.

Mehr als 32 Bits schaffen keine gemeinsame Sprache

Die ursprüngliche Administrative Group ist eine feste 32-Bit-Maske. Betreiber nennen ihre Positionen häufig Farben. Eine Farbe hat jedoch keine universelle Bedeutung: Dieselbe Position kann in einem Netz geringe Latenz, in einem anderen Wartung oder eine geografische Einschränkung bezeichnen.

RFC 7308 führte die EAG ein, damit mehr als 32 Attribute darstellbar sind. Sie bleibt eine Folge von 32-Bit-Wörtern und ist praktisch durch das tragende Protokoll begrenzt. RFC 9104 schafft die Projektion dieses IGP-Link-Attributs in BGP-LS.

Das neue Feld ersetzt das alte nicht. Administrative Group TLV 1088 und EAG TLV 1173 dürfen nebeneinander stehen. Beschreiben beide denselben Link, müssen die ersten 32 EAG-Bits identisch mit der AG sein. Der Empfänger verwendet AG für die Bits 0 bis 31 und EAG ab Bit 32; eine Abweichung sollte dem Betreiber gemeldet werden.

Das ist eine Konsistenzprüfung der Darstellung, keine Prüfung des Wörterbuchs. Zwei identische Masken können mit derselben veralteten Zuordnung falsch gedeutet werden.

Syntax hat eine feste Folge, Semantik einen lokalen Eigentümer

RFC 9104 zieht für Syntaxfehler eine klare Linie. Ist die Länge des TLV 1173 kein Vielfaches von vier, gilt es als malformed. Der zugehörige BGP-LS Attribute wird nach den einschlägigen Regeln verworfen. Über diese Form kann ein Parser entscheiden.

Semantische und inhaltliche Prüfung liegen dagegen beim Consumer. Er prüft auch die Zuordnung zum passenden NLRI- oder Attributtyp und legt die Anwendungsreaktion fest. Consumer behavior liegt ausdrücklich außerhalb des Geltungsbereichs von RFC 9104.

Erfolgreich gelesene 64 Bits beweisen deshalb nicht, dass Bit 42 weiterhin „bei Wartung meiden“ bedeutet, eine aktive Policy darauf verweist oder unbekannte Bits vorsichtig behandelt werden.

RFC 9552 ersetzte 2023 die BGP-LS-Grundspezifikation RFC 7752 und beschreibt das heutige Verteilungsmodell genauer: Topologie- und Traffic-Engineering-Informationen gelangen aus LSDB oder TED an externe Consumer. Das erläutert die aktuelle Architektur, ist aber kein rückwirkender Nachweis für das Verhalten eines konkreten Controllers im Jahr 2021.

Das Farbenwörterbuch steckt nicht im TLV

Aus dem Format lässt sich eine wichtige Abwesenheit ableiten. TLV 1173 transportiert Länge und Bitmasken. Es transportiert keine Bezeichnung wie „geringe Latenz“, keine Wörterbuchversion, keine Policy-Reihenfolge, keinen Genehmiger, keine Pfadkandidaten, keinen Siegerpfad und keinen FIB-Status.

Dies ist eine ausdrücklich gekennzeichnete Folgerung aus der Felddefinition, kein angebliches RFC-Zitat. Ein Producer kann die aktuelle EAG an einen Consumer mit gestrigem Katalog senden. Zwei Consumer können denselben Wert wegen verschiedener Regeln für unbekannte Bits unterschiedlich behandeln. In einer Migration kann ein neues Bit aktiv werden, bevor alle Systeme seine Definition erhalten haben.

RFC 7308 behandelt nicht angekündigte Bits im Allgemeinen als null, lässt aber eine lokale Strategie zu. Gerade deshalb muss das tatsächliche Consumer-Verhalten dokumentiert werden.

Sieben Belege statt einer grünen Anzeige

Der Quellbeleg nennt IGP-Instanz, Protokoll, Link, LSA oder LSP, EAG-Wert und Beobachtungszeit. Der Projektionsbeleg hält BGP-LS-Producer, Link-NLRI-Deskriptoren, Protocol-ID, Sitzung, Länge und Rohwert von TLV 1173 sowie gegebenenfalls den Vergleich mit TLV 1088 fest.

Der Consumer-Beleg dokumentiert Parsing, semantische Prüfung, Link-Zuordnung, Wörterbuchversion und Unknown-Bit-Regel. Der Policy-Beleg benennt ein- und ausgeschlossene Bits, Prioritäten, Konfliktregeln, Genehmigung und Rollback-Befugnis.

Der Berechnungsbeleg bindet Topology Epoch und Policy-Version an Kandidaten, Ausschlüsse und gewählten Pfad. Der Ausführungsbeleg beschreibt Southbound-Transaktion und RIB-, FIB- oder Label-Zustand. Der Servicebeleg beobachtet Paketpfad und relevante Wirkung.

Empfangen ist nicht Verstehen. Verstehen ist nicht Anwenden. Berechnen ist nicht Installieren. Installieren ist nicht Liefern. Diese Trennung macht einen Fehler lokalisierbar, statt eine gesunde Sitzung zur Generalgarantie zu erklären.

Sicherheit, Aktualität und Wirkung bleiben eigenständig

RFC 9104 ändert das BGP-Sicherheitsmodell nicht. Sie setzt voraus, dass die erzeugenden IGP-Instanzen die nötigen OSPF- oder IS-IS-Sicherungsmechanismen verwenden. Die Anwesenheit von TLV 1173 authentisiert die Quelle nicht von selbst, autorisiert keinen Consumer und garantiert keinen sicheren Pfad.

Auch Aktualität zum Berechnungszeitpunkt ist nicht enthalten. Ein beim Export korrekter Wert kann später mit einer anderen Topology Epoch kombiniert werden. Eine richtige Policy auf veralteten Eingaben kann ein unerwartetes Ergebnis liefern.

Benachbarte Standards haben andere Gegenstände. RFC 9917 behandelt umgekehrte Administrative-Group-Bedingungen in Flex-Algorithm. RFC 9825 behandelt geordnete OSPF-Administrative-Tags und mögliche Kapazitätskürzungen. RFC 9104 projiziert eine EAG-Bitmaske in BGP-LS; die Nachweise sind nicht austauschbar.

Eine genaue Behauptung bewahrt den Wert des Standards

Ein stabiler Code Point, reproduzierbare Codierung und festgelegtes Verhalten bei Fehlformaten sind echte Interoperabilitätsgewinne. Die Behauptung auf das Beobachtete zu begrenzen, schmälert sie nicht.

Lu Hengs Texte über Running-Code Primacy und Minimum Initial Specification dienen hier als offengelegte redaktionelle Perspektive: Ein Koordinationsartefakt ist noch kein implementiertes, validiertes und genutztes Ergebnis; eine kleine gemeinsame Schicht kann Interoperabilität sichern und spätere lokale Entscheidungen lokal lassen. Sie belegen weder die Absicht der RFC-Autoren noch eine konkrete Implementierung.

Ein Betriebsbericht darf den ersten Satz so beenden: „Die EAG dieses Links ist unverändert in einem gültigen TLV 1173 angekommen.“ Behauptungen über Entscheidungen oder Netzverhalten beginnen danach – mit eigenen Belegen.

Quellen