Zusammenfassung

  • Im Beispiel eines SPRING-Arbeitsgruppenentwurfs verteilt CP1 200 Mbit/s auf zwei gleich gewichtete Segmentlisten mit angenommenen 100 Mbit/s Kapazität je Liste. Fällt eine aus, kann CP1 nach dem empfohlenen Kriterium aus RFC 9256 gültig bleiben, obwohl die angenommene Restkapazität nur noch 100 Mbit/s beträgt.
  • Der Entwurf schlägt eine Mindestzahl gültiger Listen und ein Mindestgewicht ihrer Summe vor. Ein Betreiber kann CP1 damit früher ausscheiden lassen, muss die Schwellen aber an tatsächlicher Kapazität und Last ausrichten.

Ein gültiger Pfad mit einer ungültigen Rechnung

Auf zwei gleich breite Segmentlisten verteilt sich eine Last von 200 Mbit/s sauber: jeweils 100 Mbit/s. Der SPRING-Entwurf baut genau diese Annahme in sein Beispiel ein. SL1 und SL2 haben je Gewicht 1 und eine angenommene Höchstkapazität von 100 Mbit/s. Die Flüsse werden gleichmäßig verteilt. Dann wird eine Liste ungültig. Die verbliebene Liste kann die gesamten 200 Mbit/s nicht tragen. Trotzdem darf CP1, der übergeordnete Kandidatenpfad, nach dem empfohlenen Gültigkeitskriterium der RFC 9256 aktiv bleiben: Eine gültige Liste genügt.

Das Wort „gültig“ erledigt also seine technische Arbeit und wird anschließend überfordert. Es bescheinigt einen noch benutzbaren Bestandteil des Pfads. Es bescheinigt keine Kapazität für die Last, die dem Pfad zugewiesen wurde. Wer beide Aussagen im Leitstand zu einer grünen Ampel zusammenschiebt, verlagert die fehlenden 100 Mbit/s aus dem Bericht auf die Nutzer des Dienstes.

POL1 enthält im Beispiel CP1 und CP2. CP1 ist gültig, bevorzugt und aktiv. Ein expliziter Kandidatenpfad wird nach RFC 9256 ungültig, wenn keine seiner Segmentlisten mehr gültig ist. Beim Verlust von nur SL1 kann SL2 CP1 formal im Rennen halten. Ob CP2 die Last besser tragen könnte, steht nicht im Entwurf. Sein Name als Ausweichkandidat ist noch kein Kapazitätsnachweis. Der interessante Ausfall liegt daher vor der vollständigen Invalidierung der Policy: Die bevorzugte Auswahl bleibt bestehen, obwohl ihre ursprüngliche Rechnung zerfällt.

Der Betreiber bekommt zwei Stellschrauben

Die erste heißt Minimum Valid Segment List Count und ist ein 8-Bit-Wert. Im Zweilistenbeispiel beendet ein Minimum von 2 die Gültigkeit von CP1, sobald eine Liste wegfällt. Null fügt keine Zählbedingung hinzu; 0xff verlangt die Gültigkeit sämtlicher Listen. Die zweite Stellschraube ist das 32-Bit-Minimum für das kumulierte Gewicht gültiger Listen. Bei den Gewichten 1 und 1 führt auch hier ein Minimum von 2 zum Ausscheiden nach einem Listenverlust. Null hebt die zusätzliche Gewichtsbedingung auf; 0xffffffff verlangt wiederum alle Listen. Sind beide Schwellen gesetzt, müssen beide erfüllt sein. Stehen beide auf null, bleibt das Verfahren der RFC 9256 maßgeblich.

Zählen ist transparent, aber grob. Zwei Listen können sehr verschiedene Bandbreiten haben. Das Gewicht kann diese Unterschiede abbilden, sofern jemand die Abbildung pflegt. Es ist zunächst ein relativer Wert für die Verkehrsverteilung und kein Messgerät für Mbit/s. Der Entwurf kann aus den beiden Einsen eine sinnvolle Summe für 200 Mbit/s bilden, weil er je 100 Mbit/s Kapazität ausdrücklich voraussetzt. Ändert sich ein Engpass, ohne dass Gewichte und Schwelle angepasst werden, stimmt die Summe noch und die Aussage über Kapazität nicht mehr.

Der Headend kann die Parameter laut Entwurf etwa aus lokaler Konfiguration, PCEP oder BGP erhalten. Die konkreten Protokollerweiterungen werden anderswo beschrieben; dieses Dokument beantragt keine IANA-Zuteilung. Damit ist die Schlüsselfrage keine nach dem schönsten Feldnamen. Sie lautet: Wer verantwortet die Schwelle für einen bestimmten Dienst, wer verteilt sie, und wie belegt der Betreiber, welche Version der Headend wirklich anwendete? Eine zentrale Definition des Formats ersetzt diese lokale Entscheidung nicht.

Drei Zustände, drei Folgen

RFC 9256 kennt Regeln, nach denen eine Segmentliste ungültig wird. Ein Kandidatenpfad kann gültig bleiben, wenn eine andere Liste überlebt. Die gesamte SR Policy wird erst ungültig, wenn sämtliche Kandidatenpfade ungültig sind. Ändert sich die Gültigkeit eines Kandidaten, muss die Auswahl erneut ausgeführt werden; der gültige Kandidat mit der höchsten Präferenz gewinnt. Die neuen Schwellen greifen in der Mitte ein. CP1 kann ausscheiden, bevor seine letzte Liste verschwindet.

Das ist ein anderer Hebel als Drop-Upon-Invalid, die optionale Behandlung einer bereits vollständig ungültigen Policy. Hier kann die Policy lange vor diesem Punkt einen Kandidaten führen, der rechnerisch nicht mehr zur Last passt. Ein früheres Ausscheiden schafft die Gelegenheit, CP2 neu zu bewerten. Es garantiert dessen Eignung nicht. Eine gute Ersatzstrecke braucht eigene Zahlen, keine geliehene grüne Lampe.

Der Entwurf liefert ein konstruiertes Beispiel, keine Produktionsmessung einer Überlast. Für eine Aussage über reale Wirkung bräuchte man die gesetzten Schwellen, gemessene Last, verfügbare Kapazität und das Ergebnis der Neuauswahl. Der Beleg aus dem Entwurf reicht für die präzise Warnung: Das Standardprädikat und die Kapazitätszusage können auseinanderlaufen.

Der Status braucht eine Quittung

Beim Verlust einer Liste sollte ein Betreiber nachvollziehen können, wie viel Verkehr CP1 tragen sollte, welche Listen noch gültig waren, welche Anzahl und Gewichtssumme daraus folgten, welche Mindestwerte galten und woher sie kamen. Meldet ein Controller den Wert 2, während der Headend 0 benutzt, ist der Unterschied der Kern des Vorfalls. Kapazitätsänderungen gehören mit Gewichts- und Schwellenänderungen in dieselbe Historie. Nur so lässt sich später sagen, was die Anzeige „gültig“ zu diesem Zeitpunkt tatsächlich bewies.

Quellen