Zusammenfassung

  • Die IETF veröffentlichte Revision 38 ihres BGP-LS-Entwurfs zur Inter-AS-Topologie am 19. August um 09:22:08 UTC. Gegenüber Revision 37 entfernt die einzige inhaltliche Textänderung den Multi-Topology Identifier, TLV 263, aus der vorgeschlagenen Inter-AS-Link-Deskriptorliste.
  • MT-ID bleibt Teil von BGP-LS. Geändert wird die vorgeschlagene Identität des neuen NLRI; entscheidend sind nun saubere Rückzüge, eindeutige Halb-Link-Paare und die Trennung von Nicht-Standard-Topologien.

Ein Topologie-Controller kennt eine Verbindung nur durch die Felder, die sie identifizieren. Melden zwei autonome Systeme je eine Richtung desselben Links, muss der Empfänger entscheiden, welche beiden Datensätze zusammengehören. Eine gestrichene Zeile kann deshalb die Objektidentität verändern.

Laut Datatracker-Verlauf wurde draft-ietf-idr-bgpls-inter-as-topology-ext-38 am 19. August um 09:22:08 UTC verfügbar. Ein strukturierter Vergleich der offiziellen Revisionen 38 und 37 zeigt neben Versionsnummer und Datum genau eine fachliche Änderung: Die Zeile mit TLV 263 fehlt.

Der Entwurf will eine Lücke zwischen IGP-Domänen schließen. BGP-LS nach RFC 9552 kann die Topologie einer Domäne an einen Consumer wie eine SDN-Anwendung liefern. Betreibt ein Unternehmen mehrere IGP-Domänen und ASes, kennt der Controller zwar deren interne Karten, aber nicht automatisch die Verbindungen dazwischen.

Dafür schlägt das Dokument NLRI-Typ 7 als Inter-AS Link NLRI vor. TLV 270 trägt die Nummer des entfernten AS, TLV 271 beziehungsweise 272 die IPv4- oder IPv6-Kennung des entfernten Grenzrouters. Beide Enden melden jeweils einen gerichteten Halb-Link; der Consumer muss sie zu einer logischen Verbindung zusammensetzen.

Revision 37 führte nach den neuen Remote-Feldern noch lokale und entfernte Link-Kennungen, IPv4-Interface- und Nachbaradressen, die entsprechenden IPv6-Adressen sowie MT-ID auf. Revision 38 beendet die Liste nach der IPv6-Nachbaradresse. Der folgende Warnsatz bleibt bestehen: Andere TLVs als Deskriptoren können die Korrelation beider Halb-Links erschweren, wenn Producer sie unterschiedlich umsetzen.

Die Änderung ist enger als eine Abschaffung von MT-ID. RFC 9552 definiert TLV 263 weiterhin als Multi-Topology Identifier. Bei einem gewöhnlichen Link NLRI muss er enthalten sein, wenn der IGP-Link einer Nicht-Standard-Topologie angehört; für jede Topologie ist ein eigener NLRI erforderlich. Auch die Sicherheitsbetrachtung von Revision 38 nennt MT-ID weiterhin als kritische Netzinformation.

Betroffen ist der vorgeschlagene Identitätssatz des neuen Inter-AS-Objekts. Ein Producer nach Revision 37 kann TLV 263 in den Schlüssel aufnehmen, einer nach Revision 38 kann ihn auslassen. Behandelt der Consumer beide Varianten als verschiedene Schlüssel, bleibt derselbe Halb-Link doppelt vorhanden. Führt er sie zu grob zusammen, kann er verschiedene Topologien vermischen.

Für den Übergang existiert bereits eine Regel. RFC 9552 verlangt beim Hinzufügen, Entfernen oder Ändern eines TLV in einem Link-State NLRI den Rückzug des alten NLRI. Andernfalls können doppelte und widersprüchliche Link-State-Objekte in der BGP-LS-Tabelle verbleiben. Das beschreibt einen notwendigen Test, keinen beobachteten Produktionsvorfall.

Auch das IANA-Register für BGP-LS ist noch nicht auf dem Stand des neuen Textes. Bei der Abfrage am 19. August wies es den 7. August als letztes Aktualisierungsdatum aus, nannte Typ 7 Stub Link NLRI und verwies auf Revision 17. Revision 38 nennt ihn Inter-AS Link NLRI. Die Bezeichnungen der TLVs 270 bis 272 passen bereits zu Remote AS und Remote ASBR, verweisen aber ebenfalls auf Revision 17.

Die Datatracker-Statusseite zeigt den laufenden Prozess. Der Internet-Draft zielt auf Proposed Standard, liegt der IESG vor und befindet sich in AD Followup. Die IANA-Prüfung steht auf Version Changed - Review Needed, die Expertenprüfung auf Expert Reviews OK. Es gibt noch keinen RFC und keinen veröffentlichten Interoperabilitätsnachweis.

Die zusätzliche Sichtbarkeit hat eine Sicherheitsgrenze. Der Entwurf betrachtet mehrere ASes unter einer einzigen Verwaltungsinstanz und stuft Adressen, AS- und Link-Kennungen sowie Topologieinformationen als kritisch ein. Sie sollen im abgeschotteten Betriebsbereich bleiben oder vor dem Verlassen gefiltert werden. Dieselbe Karte, die Automatisierung ermöglicht, kann interne Struktur offenlegen.

Für den Betrieb ergibt sich eine klare Abnahmeprüfung: Die Identität nach Revision 37 muss verschwinden, genau eine neue Identität verbleiben, beide Halb-Links müssen korrekt zusammenfinden, Nicht-Standard-Topologien getrennt bleiben und die Daten dürfen die vorgesehene Verwaltungsgrenze nicht überschreiten. Erst danach ist aus einer Textänderung belastbares Implementierungswissen geworden.

Quellen