Zusammenfassung

  • RFC 10005 definiert eine BGP Link Bandwidth Extended Community mit einem vier Oktett langen Gleitkommawert in Byte pro Sekunde, nicht aber dessen Ermittlung oder den Algorithmus zur gewichteten Verteilung.
  • Null, Fehlen, mehrere Werte, Transitivität und Next-Hop-Wechsel werden durch Implementierungsdefaults und lokale Policy entschieden. Eine gültige Community beweist weder aktuelle freie Kapazität noch installierte Gewichte oder gelieferten Durchsatz.
  • Pradosh Mohapatra ist einer von sechs Autoren. Der gemeinsame Standardbeitrag schafft einen eng begrenzten Träger; belastbare Aussagen entstehen erst durch die Verbindung von Quelle, Transformation, FIB und beobachtetem Verkehr.

Ein Messsystem aktualisiert die verfügbare Größe um 10:00 Uhr. Eine Schwelle verhindert ein Update, weil die Änderung als zu klein gilt. Um 10:04 Uhr folgt eine zweite Veränderung, die ebenfalls unterdrückt wird. BGP zeigt weiterhin denselben Wert, und das Dashboard färbt ihn grün, weil die Route frisch empfangen wurde. Tatsächlich stammt die zugrunde liegende Evidenz aus einer älteren Lage.

RFC 10005 empfiehlt Verfahren zur Begrenzung von Churn, weil schnell wechselnde Werte Protokollstabilität und Betrieb belasten können. Das ist vernünftig. Es erzeugt jedoch getrennte Uhren für Quelle, Ankündigung, Empfang, Policy-Berechnung und Hardwareinstallation. Wer nur die letzte Uhr speichert, macht aus Dämpfung scheinbare Aktualität.

Der RFC erschien im Juni 2026 im Standards Track der IETF. Genannt sind Pradosh Mohapatra, Reshma Das, Satya Mohanty, Serge Krier, Rafal Jan Szarecki und Akshay Gattani. Er standardisiert die BGP Link Bandwidth Extended Community und legt zugleich offen, wie viel betriebliche Bedeutung außerhalb des Feldes bleibt.

Ein präzises Format kann einen unbestimmten Gegenstand tragen

Die Community besitzt eine transitive Form vom Typ 0x00 und eine nicht transitive vom Typ 0x40; der Subtyp lautet 0x04. Auf zwei Oktett Global Administrator folgen vier Oktett Local Administrator. Dort liegt eine IEEE-754-Gleitkommazahl einfacher Genauigkeit in Byte pro Sekunde.

Byte pro Sekunde sind nicht Bit pro Sekunde. Eine Anzeige in Gbit/s multipliziert mit acht, skaliert und rundet möglicherweise. Rohbytes, dekodierter Wert, Ursprungseinheit und Darstellungstransformation müssen getrennt erhalten bleiben. Sonst kann eine spätere Untersuchung die Route nicht mehr mit der sichtbaren Zahl verbinden.

Das Feld trägt aber keine semantische Kennzeichnung. Es kann Interface-Rate, entfernte Pfadsumme, Messwert, Konfiguration, Servergewicht oder Wartungssignal bedeuten. RFC 10005 lässt die Berechnung beziehungsweise Bestimmung des Werts ausdrücklich außerhalb seines Umfangs.

Darum benötigt jeder Wert einen Begleitbeleg: kontrollierte Bedeutung, Quellsystem, Mess- oder Konfigurationsmethode, Beobachtungszeit, Gültigkeitsfenster und Verantwortlicher. Eine gemeinsame Einheit macht zwei Werte nicht automatisch addierbar.

Der Internet-Draft draft-ietf-bess-ebgp-dmz-10 vom April 2026 illustriert diese Trennung, ist aber noch kein endgültiger RFC. Ein entfernter Wert von 70 Gbit/s kann über einen lokal nur mit 50 Gbit/s erreichbaren Next Hop eintreffen. Eine lokale Begrenzungsfunktion kann den Beitrag auf 50 reduzieren. Das Beispiel liefert Prüfideen, keine zusätzliche normative Garantie.

Zwei Oktett sind kein Herkunftsnachweis

Im Global Administrator sollte die ASN des Routers stehen, der die Community anfügt. Das Feld darf jedoch jeden Zwei-Oktett-Wert enthalten. Eine Vier-Oktett-ASN wird durch AS_TRANS dargestellt. Für Verwendung und Semantik der Community ist das Feld ohne Wirkung.

Es beweist daher nicht, wer gemessen, genehmigt oder Kapazität bereitgestellt hat. Sprecheridentität muss aus Session, Nachbar, Address Family, Verwaltungsdomäne und dem Policy-Ereignis kommen, das die Community anfügte.

Auch die Wahl zwischen transitiver und nicht transitiver Form gehört in den Nachweis. Während einer Migration kann eine ältere Implementierung nur eine Form verstehen. Eine Kopie wird aktualisiert, die andere bleibt stehen. Ein nachgelagerter Router berechnet aus zwei formal erkennbaren, aber zeitlich widersprüchlichen Werten ungeeignete Gewichte.

Monitoring sollte Typ, Rohwert und Alter aller Kopien vergleichen. Abweichende Werte in beiden Transitivitätsformen sind ein Alarm, kein Anlass, still eine bevorzugte Zahl zu rendern.

Kapazitätswerte können zudem vertrauliche Informationen offenlegen. RFC 10005 empfiehlt Filterung an Grenzen zu anderen Verwaltungsdomänen oder nicht vertrauenswürdigen Netzen. Die Ausführung ist zu belegen: Grenze, Policy-Version, betroffene Route, entfernte oder beibehaltene Community und genehmigte Ausnahme.

Am Next Hop stehen drei verantwortliche Verben

Ändert ein BGP-Speaker bei der Weitergabe den Next Hop, darf er die Community entfernen, unverändert behalten oder neu erzeugen. Die Implementierung sollte ihr Default offenlegen und eine Übersteuerung pro Session anbieten. Bleibt der Next Hop gleich, sollte sie die Community nicht verändern.

Entfernen beendet die nachgelagerte Nutzung der ursprünglichen Aussage. Behalten transportiert sie, ohne lokale Evidenz hinzuzufügen. Neuerzeugen macht aus lokalen Inputs eine neue Aussage. Selbst identische Eingangs- und Ausgangswerte besitzen danach eine andere Autorität und Uhr.

Der Endwert enthält kein Transformationsprotokoll. Deshalb müssen alter und neuer Next Hop, Input, Aktion, lokale Eingaben, Policy-Version, Output, Zeit und Entscheider separat gespeichert werden.

Hier liegt ein Agency-Problem. Originator, Zwischenrouter, Empfänger, Plattform und Betrieb beeinflussen nacheinander Bedeutung oder Wirkung. Bleibt nur die letzte Zahl, verschwindet die Zuständigkeit aller Übergaben.

Null, fehlend, ungültig und veraltet brauchen eigene Zustände

Null ist gültig und kann in einer Wartung angekündigt werden. Die Empfänger-Policy entscheidet, ob der Nullpfad ausgeschlossen, auf Gleichverteilung zurückgefallen oder eine andere Regel angewandt wird. Auch wenn alle Werte null sind, gibt es keine universelle Bedeutung.

Fehlen ist ein anderer Fall. Hat ein Multipath keine gültige Community, ist Equal Load Balancing der Default, sofern Konfiguration ihn nicht ändert. Negative Werte sollten nicht erzeugt werden und werden vom Empfänger ignoriert. Ein positiver Wert nach Ablauf seiner Quellgültigkeit ist formal korrekt, aber stale.

Ein gemeinsamer Status unknown verhindert gezielte Reaktion. Null kann Drain bedeuten, Fehlen mangelnde Unterstützung, ungültig einen Origin-Fehler und stale eine Dämpfungsfolge. Jeder Zustand braucht eigenen Owner und Rückfall.

Trägt eine Route mehrere Link Bandwidth Communities, wird für gewichtete Verteilung standardmäßig der niedrigste Wert einschließlich null verwendet; Konfiguration kann diese Präferenz ändern. Der Beleg muss Kandidaten und Auswahlregel enthalten, nicht nur das angezeigte Ergebnis.

Berechnetes Gewicht ist noch keine ausgeführte Verteilung

Sind alle beitragenden Werte positiv, können Werte oder Relationen als Gewichte dienen. Der konkrete Algorithmus bleibt außerhalb des RFC. Der Wert sollte nicht in die BGP-Best-Path-Entscheidung eingehen, sondern erst zwischen bereits geeigneten Multipaths wirken.

Software kann 2:5 berechnen, während die FIB auf verfügbare Buckets rundet. Hardware kann bestehende Flows wegen Resilient Hashing erhalten. Wenige große Flows können die Byteverteilung trotz korrekter Buckets verschieben.

Vier Belege gehören zu derselben Generation: empfangene Communities, berechnete Gewichte, installierte FIB- beziehungsweise ECMP-Gewichte und beobachteter Verkehr je Pfad. Ein Konfigurationsdiff ersetzt keine Hardwarebestätigung; eine Hardwarebestätigung ersetzt keine Messung.

Auch eine passende Verteilung belegt keine freie Kapazität. Leitungsrate, erreichbarer Engpass, momentaner Headroom und gelieferter Durchsatz sind verschiedene Größen. Loss, Latenz, Queue-Tiefe und Congestion müssen neben Bytes und Paketen stehen.

Churn-Schutz darf Alter nicht unsichtbar machen

Quelle, Ankündigungsentscheidung, Versand, Empfang, Berechnung und Installation benötigen eigene Zeitstempel. Unterdrückte Änderungen bleiben Audit-Ereignisse. Erst dann kann der Betrieb erkennen, ob eine ruhige Zahl stabil oder nur nicht weitergegeben wurde.

Für den Ablauf braucht es eine festgelegte Entscheidung: Gleichverteilung, Isolation, letzter Wert mit Warnung oder Rückzug. Ebenso wichtig ist die maximal zulässige Dauer, in der stale Evidenz noch Hardware beeinflussen darf.

Diese Trennung folgt der Priorität von Running Code. Eine Policy beschreibt die erlaubte Reaktion. Der Prozess zeigt die Auswahl. Die FIB zeigt die Installation. Telemetrie zeigt die Wirkung. Kein früher Zustand darf für einen späteren sprechen.

Pradosh Mohapatras Beitrag ist kollektiv und begrenzt

RFC 10005 nennt Pradosh Mohapatra mit der Zugehörigkeit Google LLC und fünf weiteren Autoren. Das am 1. September 2026 erfasste offizielle Datatracker-Profil zum Dokument listete elf RFCs, zeigte jedoch die ältere Schreibweise „Prodosh Mohapatra“. RFC 10005 und die öffentliche ipSpace-Seite verwenden „Pradosh Mohapatra“, die hier als kanonische Identität gilt.

Die datierte ipSpace-Biografie nennt frühere Routing-Software-Aufgaben bei Cumulus Networks und Cisco. Das ist Identitäts- und Berufskontext, kein Beleg für eine heutige Rolle über die RFC-Zugehörigkeit hinaus, für Kontrolle über IETF-Konsens oder für ein konkretes Betriebsergebnis.

Ein Personenprofil darf aus sechs Autoren keinen alleinigen Erfinder machen. Der überprüfbare Beitrag liegt in der Grenzziehung: Mohapatra und seine Koautoren standardisieren einen Träger und die interoperable Verarbeitung, ohne lokale Bestimmung als globale Kapazitätswahrheit auszugeben.

Einen Beleg vom Ursprung bis zum Verkehr bauen

Der Datensatz beginnt mit Route, Address Family, Nachbar, Domäne, Typ, Global Administrator, Rohbytes, Byte-pro-Sekunde-Wert und Anzeigeumrechnung. Daran kommen Bedeutung, Quelle, Methode, Beobachtung, Gültigkeit und Owner.

Jeder Next-Hop-Wechsel erhält remove, retain oder regenerate samt Ein- und Ausgang. Aggregation erhält Bestandteile, Formel und Behandlung von null, fehlend und ungültig. Empfang erhält Policy-Version und Relation. Ausführung erhält FIB, Hardwarebestätigung und Pfadverkehr.

Loss, Latenz, Queue, Alarm, Entscheidung, Rollback und stale cleanup schließen die Kette. So bleibt die Community ein nützlicher Routinginput. „Verfügbare Kapazität“ wird zu einer gesonderten, prüfbaren Aussage, deren Belege außerhalb der vier Oktett liegen.

Quellen