Zusammenfassung

  • Ein erreichbarer BGP-NEXT_HOP bleibt notwendig; Tunnel und Segment Routing können die reale Weiterleitung jedoch von einem anderen Endpunkt, Kontext und Datenbestand abhängig machen.
  • Das vorgeschlagene Pfadauflösungstupel hält Auflösbarkeit, Präferenz, Metrik und Tracking in derselben Auflösung. Installation und Zustellung bleiben getrennte Nachweise.

Eine Adresse, mehrere Weiterleitungswelten

RFC 4271 geht davon aus, dass ein BGP-Sprecher die Erreichbarkeit und den internen Aufwand bis NEXT_HOP ermitteln kann. Bei GRE, MPLS, SR Policy und SRv6 reicht das nicht. Die Steuerungsadresse kann erreichbar sein, während der relevante Tunnelendpunkt, die Policy oder die Service-SID fehlt.

Revision 00 von BGP Best Path Selection Based on Next Hop Resolution erschien am 24. September 2026 als Standards-Track-Internet-Draft der IDR-Arbeitsgruppe. Bei Annahme würde sie RFC 4271 aktualisieren. Sie ist weder RFC noch endgültiger Konsens und belegt keine Verbreitung.

Der Entwurf definiert das Pfadauflösungstupel: einen Auflösungsschlüssel mit optionalem Kontext. Schlüssel können der gewöhnliche NEXT_HOP, der Tunnel Egress Endpoint aus RFC 9012 oder eine SRv6-Service-SID aus RFC 9252 sein. Der Kontext bestimmt Verfahren und Datenbestand, etwa Tunnel Encapsulation, eine Color Extended Community oder SRv6-Sub-TLV-Informationen außer der SID.

{N1, C1} und {N1} sind damit trotz gleichen Schlüssels verschiedene Anfragen. Eine Auflösung über SR Policy ist kein Ersatz für eine gewöhnliche Next-Hop-Abfrage.

Die Beweise dürfen nicht zusammengesetzt werden

Auflösbarkeit, Schlüsselpräferenz, Metrik und Trackingzustand eines Pfades müssen dieselbe Auflösung beschreiben. Wer Erreichbarkeit aus Kontext A und eine günstigere Metrik aus Kontext B kombiniert, erzeugt einen Pfad, den kein System tatsächlich aufgelöst hat.

Auflösungsbedingungen begrenzen die zulässigen Routen und Datenbestände. Sie können einen Tunneltyp verlangen, Aggregatauflösung verbieten oder Transportklassen ordnen. Sie sind lokale Zulassungsregeln und kein weiteres Tupelfeld.

Die normale NEXT_HOP-Prüfung bleibt bestehen. Hinzu kommt die konfigurierbare, bedingte Tupelprüfung. Ein verfügbares Tunnelobjekt rechtfertigt daher nicht, einen defekten herkömmlichen Next Hop zu übergehen.

Auch Metriken sind nicht allein wegen ihrer Zahlenform vergleichbar. Ein Wert kann IGP-Kosten, ein anderer Latenz bedeuten; eine Auflösung liefert möglicherweise gar keinen Wert. Eine lokale numerische Auflösungsschlüsselpräferenz, bei der kleinere Werte gewinnen, ordnet zunächst ungleiche Mechanismen. Danach darf der interne Aufwand nur aus dem betreffenden Tupel stammen. Fehlt dort eine Metrik, gilt der maximal erlaubte Aufwand.

Acht getrennte Belege

Der Anzeigenachweis hält Route, NEXT_HOP und Attribute fest. Der Tupelnachweis enthält Schlüssel, Kontext und Ableitung. Der Bedingungsnachweis nennt lokale Regel und zulässigen Datenbestand. Der Auflösungsnachweis bindet Erreichbarkeit, Präferenz, Metrik, Weiterleitungsdaten und Zeitpunkt atomar.

Der Auswahlnachweis zeigt Kandidaten, Filter und Entscheidung. Der Trackingnachweis identifiziert Abonnements für den gewöhnlichen Next Hop und jedes kontextverschiedene Tupel, auch für Nicht-Bestpfade. Der Installationsnachweis beobachtet RIB, FIB und Kapselung. Der Zustellnachweis misst Paketpfad und Dienstergebnis.

Auswahl beweist keine Installation; Installation beweist keine Zustellung. Genannte Risiken wie Überlastung, Paketverlust und Fehlleitung sind Problemszenarien, keine Einsatzstatistik und kein Wirksamkeitsbeleg.

Kontextidentität im Tracking erhalten

BGP sollte sowohl den gewöhnlichen NEXT_HOP als auch das Tupel verfolgen. Wird eines unauflösbar oder ändert sich die tupelbezogene Metrik, müssen alle betroffenen Präfixe neu bewertet werden.

Gleiche Schlüssel mit verschiedenen Kontexten brauchen getrennte Abonnements. Auch Nicht-Bestpfade müssen beobachtet werden, weil sie ohne neue Anzeige wieder zulässig werden können. Eine Zusammenführung von {N1, C1} und {N1} beseitigt genau die Beweisgrenze, die das Tupel schaffen soll.

Kleine gemeinsame Regel, lokale Präferenz

Das entspricht Heng Lus Konzept einer minimalen Anfangsspezifikation mit lokalisierten Folgeentscheidungen. Der gemeinsame Standard kann Tupelidentität und Mischverbot festlegen, ohne weltweit einen Transport zu bevorzugen. Bedingungen, Präferenzen und Einführungszeitpunkt bleiben lokal.

Seine Trennung von Autorität und Glauben gilt ebenfalls: Eine Anzeige belegt, was angekündigt wurde; eine Auflösung, was ein System fand. Keines beweist den tatsächlichen Paketweg. Running-Code Primacy verlangt Softwareversionen, atomare Protokolle, programmierten Zustand und Paketbeobachtung.

Color kann Teil eines Kontextes sein, doch die Frage ist nicht mit den Transportklassen aus RFC 9830 gleichzusetzen. Hier geht es nicht um Color-Import oder SLA, sondern darum, ob alle Fakten einer BGP-Entscheidung dieselbe Auflösung meinen.

Status und Grenzen

Revision 00 empfiehlt konsistente Konfiguration im Verwaltungsbereich. Das reduziert unterschiedliche Entscheidungen, beweist aber nicht die Übereinstimmung mit der Datenebene. Falsche Bedingungen, veraltete Bestände und abweichende Präferenzen bleiben Risiken, auch wenn der Entwurf keine zusätzlichen Sicherheitsüberlegungen gegenüber bestehendem NEXT_HOP nennt.

Text und Implementierungen können sich ändern. Der unmittelbare Wert liegt in einer klaren Verbotsregel: Aus Fakten über mehrere Pfade darf nicht der Anschein eines einzigen Pfades entstehen.

Quellen