Zusammenfassung

  • Revision 34 verlangt von einem fähigen Peer, bei 0% Site Physical Availability sämtliche dem Site-ID zugeordneten Routen für die Weiterleitung als nicht verfügbar zu behandeln – mit der Wirkung einzelner Withdrawals, aber ohne jede Route einzeln zurückzuziehen.
  • Im normalen BGP können dieselben Routen gültig bleiben. Herkunft, Mapping-Generation, lokale Entscheidung, RIB, FIB, bestehende Flows und Dienstresultat brauchen deshalb getrennte Belege.

Um 09:14 Uhr verliert ein Edge-Standort seinen letzten einsatzfähigen Server. Der Egress-Router sendet genau ein BGP UPDATE mit Site-ID und physischer Verfügbarkeit null. Dutzende Präfixe bleiben in der BGP-Tabelle des Ingress-Routers sichtbar, sind für metadatengesteuerte Dienste aber nicht mehr wählbar. Es gibt keinen Schwall einzelner Withdrawals. Das Routing-Team sieht vorhandene Pfade; die Anwendung erlebt einen verschwundenen Standort.

Dieser Unterschied ist die operative Pointe von Revision 34 des Entwurfs BGP Extension for 5G Edge Service Metadata. Sie wurde am 25. September 2026 angenommen, die Titelseite trägt den 23. September. Das Dokument bleibt ein IDR-Working-Group-Internet-Draft im Zustand I-D Exists. Auf der Titelseite steht Standards Track, während das entsprechende Datatracker-Feld leer ist. Shepherd, verantwortlicher Area Director und Telechat fehlen; ein Meilenstein für Juli 2027 zielt auf den Working Group Last Call. Das ist weder RFC noch zugeteilter IANA-Codepunkt, Implementierung, Interoperabilitätsnachweis oder Betriebserfahrung.

Eine kleine Nachricht übernimmt eine große Zuordnung

Der Entwurf definiert ein optionales, nicht transitives Edge Metadata Path Attribute. Eine Route kann ein Dienstpräfix einem 16-Bit-Site-ID zuordnen. Ein eigenständiges Update übermittelt später dynamische Standortdaten, ohne sie auf jeder Route zu wiederholen. Dabei ist das NLRI die Loopback-Adresse des Egress-Routers, RouteFlag-I ist null, und die Nachricht gilt für bereits zugeordnete Routen. Ist RouteFlag-I eins, wird die Zuordnung hergestellt; der Prozentwert bleibt unbeachtet.

Für den Nullfall ist Revision 34 eindeutig: Ein unterstützender Speaker muss alle zugeordneten Routen für die Weiterleitung als nicht verfügbar behandeln. Die Wirkung entspricht einem Einzel-Withdrawal jeder Route, obwohl diese Meldungen nicht versendet werden. Ein Peer ohne Edge Metadata benötigt dagegen weiterhin normale BGP-Withdrawals.

„Entspricht“ beschreibt also die Auswahlwirkung innerhalb des Mechanismus, nicht identische Zustände. Der Entwurf erlaubt an anderer Stelle, dass eine von der Metadatenauswahl ausgeschlossene Route für gewöhnliche BGP-Erreichbarkeit gültig bleibt. Das Präfix kann im RIB stehen und zugleich für eine Dienstklasse unzulässig sein. Diese Trennung verringert Churn und unterscheidet Anwendungszustand von Netzreichweite. Sie macht aber auch klar: Grüne Session und vorhandene Route sind kein Beweis für einen verfügbaren Dienst.

Der Nullwert trägt seine Zielmenge nicht mit

Das eigenständige Update listet keine betroffenen Präfixe auf. Seine Fächerwirkung hängt von früheren Route-zu-Site-ID-Zuordnungen beim Empfänger ab. Ordnet ein Ingress 42 Routen dem Site-ID 711 zu und ein zweiter wegen eines verpassten Updates nur 41, können beide denselben Nullwert korrekt verarbeiten und verschiedene Mengen sperren.

Ein brauchbarer Nachweis darf daher nicht bei „Site-ID 711 = 0 empfangen“ enden. Nötig ist eine versionierte Mapping-Generation mit Routenschlüsseln, Wirksamkeitszeitpunkt, Ursprung und bestätigenden Entscheidungspunkten. Anzahl und Digest der aufgelösten Zielmenge lassen Soll und Ist vergleichen, ohne jede interne Auswahl in das Protokoll zu pressen.

Generation, Quittung und Digest sind Betriebsempfehlungen dieses Beitrags, keine Anforderungen von Revision 34. Der Entwurf normiert Protokollverhalten und kein flottenweites Quittungssystem. Lokale Telemetrie, Controller-Zustand oder signierte Logs sind mögliche Lösungen. Die Implementierung darf variieren; die Frage, welche Routen der Nullwert treffen sollte, darf nicht unbeantwortet bleiben.

Autorisierte Herkunft verhindert einen Fernschalter

Ein Empfänger soll das eigenständige Availability-Update nur vom zugehörigen Egress-Router oder von einem autorisierten Route Reflector annehmen, dessen Originator-ID diesen Egress bezeichnet. Das ist entscheidend: Ein gefälschter Nullwert kann alle zugeordneten Routen unbrauchbar machen und einen Denial of Service auslösen.

Eine gültige BGP-Session beweist diese Autorisierung nicht. Ein legitimer Reflector kann eine unerwartete Originator-ID tragen. Der Egress-Loopback kann erreichbar sein, obwohl die Session eine andere Rolle besitzt. Der Beleg sollte authentifizierten Peer, AFI/SAFI, ausgehandelte Edge Metadata Processing Capability, Egress-Identität, Originator-ID, Site-ID, Attributbytes und Policy-Entscheidung festhalten.

Die Fähigkeit wird bilateral je AFI/SAFI ausgehandelt. Das Attribut ist optional und nicht transitiv; NO_ADVERTISE, ein AS-Scope-Sub-TLV und übliche Filter begrenzen die Verteilung. Unbekannte Sub-TLVs werden ignoriert, Abwesenheit darf niemals als null interpretiert werden. Das mindert Fehlverteilung, beweist jedoch weder Unterstützung an allen vorgesehenen Ingresses noch die notwendigen Withdrawals für nicht unterstützende Peers.

Messung, Verteilung und Wirkung folgen verschiedenen Uhren

Site Physical Availability reicht von null bis 100; Werte außerhalb des Bereichs werden ignoriert. Der Entwurf trennt Mess- und Ankündigungsintervall und empfiehlt ohne andere Konfiguration mindestens 30 Sekunden sowie Dämpfung oder Hysterese. Flow-Affinität bleibt implementationsabhängig: Ein bestehender Flow kann an seinem Egress bleiben, bis dieser tatsächlich unerreichbar wird.

Ein Standort kann um 09:14:00 null messen, um 09:14:12 senden, um 09:14:13 an einem Ingress wirksam werden und einen gebundenen Flow bis 09:15:00 weiterführen. Wer all das „Nullereignis“ nennt, verliert die Zeitachse zwischen Messung, Steuerung und Kundenerlebnis.

Das eigenständige Update dient auch nicht der Next-Hop-Auflösung. Es verändert die Diensteignung; es behauptet weder einen unerreichbaren Loopback noch BGP-Konvergenz. Die Beweiskette lautet: Messquelle, autorisierte Identität, Mapping-Generation, Capability, Empfang, Zielmengenauflösung, lokale Policy, RIB und FIB, Flow-Behandlung, Dienstergebnis. Der Sprung vom Update zum Kundeneffekt ersetzt Beobachtung durch Annahme.

Eine minimale Norm braucht sichtbare Ausführung

Heng Lus Prinzip der minimalen Anfangsspezifikation standardisiert nur das für Koordination notwendige gemeinsame Stück und lässt spätere oder lokale Entscheidungen offen. Hier können Standortidentität, Bedeutung des Verfügbarkeitswerts, Herkunft und Scope dieses Minimum bilden. Messalgorithmus, Ranking und Fallback bleiben lokal. Das Primat des laufenden Codes verlangt anschließend Evidenz an der Grenze, an der Protokollbedeutung zur Weiterleitungsentscheidung wird.

Für den Betrieb sollten eine Mapping-Generation, Anzahl und Digest betroffener Routen, Apply-Quittungen pro Entscheidungspunkt und ein Flow-Canary am Nullübergang verlangt werden. Das sind Vorschläge dieser Analyse, keine zusätzlichen Draft-Anforderungen. Sie schaffen überprüfbare Wirkung, ohne eine zentrale Controller-Architektur zu erzwingen.

Null ist mächtig, weil es viele Withdrawals ersetzt. Je kompakter die Aktion, desto präziser müssen die Belege sein. RIB, Metadaten-Engine und Nutzer können drei unterschiedliche, jeweils ehrliche Zustände zeigen. Vertrauen entsteht erst, wenn sie sich miteinander abgleichen lassen.

Quellen