Zusammenfassung

  • draft-ietf-idr-bgpls-inter-as-topology-ext-46 definiert einen Inter-AS Link NLRI und Deskriptoren für entfernte AS und ASBRs, damit ein BGP-LS-Konsument die Angaben beider Enden korrelieren kann.
  • Die vollständige Kante ist abgeleitet. Sie hängt von IGP- oder lokaler Herkunft, BGP-LS-Export, Filtern, Kennungen, Aktualität und der Zuordnungsregel ab.
  • Eine passende Kante beweist weder Erreichbarkeit noch Kapazität oder Pakettransport. Dafür braucht die Allianz einen Korrelationsbeleg und getrennte Ergebnisbelege.

Die fehlende Naht zwischen vollständigen Karten

Ein Controller kann die interne Topologie zweier IGP-Domänen vollständig empfangen und dennoch die Verbindung zwischen ihnen nicht kennen. Über den Inter-AS-Link läuft gewöhnlich kein IGP. Die ASBRs kennen ihren Nachbarn, aber dem BGP-LS-Konsumenten fehlt die passende Kodierung.

Revision 46 von BGP-LS Extensions for Inter-AS Topology Retrieval schlägt dafür NLRI-Typ 7 sowie Remote AS Number, IPv4 Remote ASBR ID und IPv6 Remote ASBR ID vor. Die Angaben können aus OSPF Inter-AS TE nach RFC 5392 oder IS-IS nach RFC 9346 stammen und nach RFC 9552 über BGP-LS verteilt werden.

Der Entwurf beschreibt den Link normalerweise durch Informationen von beiden Seiten. Der Konsument vergleicht lokale und entfernte AS, ASBR-Kennungen, BGP-LS Instance Identifier und gegebenenfalls Interface- oder Linkkennungen. Gelingt die Zuordnung nicht, bleibt ein ungepaarter oder unvollständiger Link.

Die fertige Kante wird somit nicht von einem einzigen Beobachter geliefert. Der Controller erzeugt sie durch einen Join.

Gleiche Felder, unterschiedliche Herkunft

Im Hauptfall erzeugt ein ASBR die Information in OSPF oder IS-IS. Ein BGP-LS-Speaker empfängt sie, bildet den NLRI und exportiert ihn gemäß Policy. Jede Stufe kann eine Seite verzögern oder ausblenden.

Der alternative Fall ist für die Bewertung entscheidend. Ein ASBR kann den NLRI aus einem direkt verbundenen Interface oder einer statischen Route erzeugen und Direct oder Static configuration als Quelle angeben. Der Controller ordnet die Gegenseiten über AS-Nummern und Adressen zu.

Eine Hälfte folgt dann IGP-Updates und Withdrawals, die andere einer Konfigurationsänderung. Werden nur die Endfelder gespeichert, verschwinden Unterschiede bei Autorität, Alterung und Reparatur.

Ein minimaler Beleg sollte für jede Seite eine stabile Referenz oder einen Digest, Quellprotokoll, BGP-LS-Instanz, lokale und entfernte AS/ASBR, Zusatzdeskriptoren, Empfangszeit, Alter und Withdrawal-Status bewahren. Danach folgen Zuordnungsregel, Policy-Version und Ergebnis: paired, unpaired, conflicting, stale oder withdrawing.

Dieser Beleg ist ein redaktioneller Vorschlag, keine Vorgabe des Entwurfs. Er zentralisiert nicht die Topologie, sondern macht eine lokale Ableitung prüfbar.

Neun Stufen statt eines grünen Symbols

Die reale Verbindung, ihre IGP- oder Konfigurationsbeschreibung, der Empfang beim Speaker, der Export, das Parsing, die Korrelation, die Aufnahme in einen Snapshot, die Pfadberechnung und -programmierung sowie der beobachtete Verkehr sind unterschiedliche Ereignisse.

Ein IANA-Codepunkt belegt eine gemeinsame Nummer. Gültige Syntax belegt Dekodierbarkeit. Ein Match belegt die Erfüllung einer Regel. Keines davon belegt Linkzustand, aktuelle Bandbreite, erfolgreiche Installation oder Dienstwirkung.

Revision 46 ist ein aktiver IDR-Arbeitsgruppenentwurf vom 29. September 2026, kein RFC. Das Quellenpaket enthält keinen öffentlichen Einsatz, Interoperabilitätstest oder gemessenen Forwarding-Erfolg. Die Early Allocations im IANA-BGP-LS-Register ermöglichen Entwicklung, zertifizieren aber keine Betriebswirkung.

Eine fehlende Gegenseite ist ein eigener Befund

Die Erweiterung lässt sich schrittweise einführen. Nur Ursprungssysteme, exportierende Speaker und Konsumenten müssen sie unterstützen. Damit sind asymmetrische Zustände unvermeidbar: eine Kennung fehlt, ein Filter entfernt nur eine Meldung, eine Session hinkt hinterher oder ein Withdrawal erreicht nur eine Seite.

Der Entwurf empfiehlt, beide ASBRs, die OSPF-/IS-IS-Anzeigen, Empfang und Export über BGP-LS, Kennungskonsistenz und Policies zu prüfen. Er fordert zudem operative Sichtbarkeit darüber, ob die Korrelation gelang.

Diese Zustände dürfen nicht in link=true verschwinden. Gepaarte, ungepaarte, widersprüchliche, veraltete, zurückgezogene und nicht unterstützte Kanten haben unterschiedliche Folgen. Eine Halbkante kann gerade der Beleg für eine Policy-Grenze sein.

Eine Datenbank kann Gleichzeitigkeit vortäuschen

Kommt Seite A um 09:00 und Seite B um 09:04 an, muss geklärt sein, ob A um 09:04 noch galt. Ein verzögertes Withdrawal kann zwei kompatible Zeilen hinterlassen, die im Netz nie gleichzeitig aktuell waren.

Der Entwurf legt kein universelles Frischefenster fest. Diese Freiheit ist sinnvoll, macht den Konsumenten aber verantwortlich. Der Beleg muss zulässige Zeitdifferenz, Haltezeit, Withdrawal-Behandlung und Snapshot-ID nennen.

„Beide Seiten stimmten überein“ darf nicht nur heißen, dass zwei Datensätze für einen Join verfügbar waren.

Vertraulich und dennoch nachvollziehbar

Das Zielszenario umfasst mehrere AS unter gemeinsamer Verwaltung. Interconnection-Adressen und Kennungen sind laut Entwurf kritische Netzinformationen, die im kontrollierten Bereich bleiben oder beim Verlassen gefiltert werden sollen.

Ein Korrelationsbeleg muss die Karte nicht veröffentlichen. Interne Referenzen, Digests, Rollenrechte und begrenzte Aufbewahrung reichen, sofern autorisierte Prüfer die Entscheidung rekonstruieren können.

Auch ein vollständiger Kartenbeleg ist kein Dienstbeleg. Der Multi-Domain-TE-Fall in RFC 8735 benötigt die Kante zur Berechnung. Programmierung, Konvergenz, Forwarding und Wirkung folgen danach.

Ein Test, der die Kante widerlegen darf

Running Code Primary verlangt mehr als Decoder-Konformität. Zwei unabhängige Implementierungen sollten passende Angaben, abweichende Remote-ASBRs, einseitiges Filtering, vertauschte Updates, verspätete Withdrawals sowie eine statische gegen eine IGP-Hälfte verarbeiten. Zu vergleichen sind Kanten und Begründungen für Erzeugung, Herabstufung und Löschung.

Zeichnen zwei Controller dieselbe Linie mit verschiedenen Zeitfenstern, endet die scheinbare Interoperabilität im Fehlerfall. Minimum Initial Specification beschränkt den gemeinsamen Vertrag auf zwei Eingaben, Herkunft, Regel, Zeitgrenze und Ergebnis. Speicherung und Pfadpolitik bleiben lokal.

Die belastbare Aussage lautet: Diese zwei Meldungen kamen in diesem Fenster aus diesen Quellen; diese Regel verband sie; kein offener Konflikt blieb; dieser Snapshot übernahm die Kante. Für installierten Pfad und Pakete gibt es eigene Belege.

Quellen

  1. BGP-LS Inter-AS Topology Retrieval, Revision 46
  2. Dokumenthistorie
  3. RFC 9552
  4. RFC 5392
  5. RFC 9346
  6. IANA BGP-LS Parameters
  7. Lu Heng — Minimum Initial Specification
  8. Lu Heng — On Reality Layers
  9. Lu Heng — Running Code Primary
  10. Revision 46 als HTML
  11. Revision 46 als Text
  12. Offizieller Diff von Revision 45 zu 46
  13. RFC 7426 — SDN-Terminologie
  14. RFC 9086 — BGP-LS Egress Peer Engineering