Zusammenfassung

  • RFC 9791 beschreibt NFFRR als Anwendungsfall: Nach einer ersten lokalen Umleitung kann eine weitere FRR denselben Verkehr in einen Loop schicken. Das Dokument definiert jedoch keine vollständige, heute zugewiesene NFFRR-Aktion.
  • Eine NFFRR-Markierung wirkt praktisch wie ein delegiertes Veto. Der erste Reparaturpunkt entscheidet, dass eine spätere lokale Zustellchance nicht genutzt werden soll — eine Entscheidung, die nur so gut ist wie die zugrunde liegenden Topologie-, Fehler-, Fähigkeits- und Vertrauensannahmen.
  • Für belastbare Verantwortung reicht das Bit nicht. Betreiber brauchen eine nachvollziehbare Kette aus Fehlerbeobachtung, Reparaturentscheidung, Topologieversion, Aktionsidentität, Fähigkeitsnachweis, Grenzbehandlung, Zählern und einem benannten Policy-Verantwortlichen.

Zwei vernünftige Reparaturen, ein unvernünftiger Loop

Das anschaulichste Beispiel steht nicht in einem Produktionsbericht, sondern in dem abgelaufenen Internet-Draft draft-kompella-mpls-nffrr-04. Die Topologie zeigt ein EVPN mit Active-Active-Multihoming: CE2 hängt an PE2 und PE3. Fällt CE2 selbst aus, sieht PE2 seinen Anschluss zu CE2 als ausgefallen und leitet betroffenen Verkehr über den Backup-Pfad zu PE3. PE3 sieht zugleich seinen eigenen Anschluss als ausgefallen und trifft spiegelbildlich dieselbe lokale Entscheidung: zurück zu PE2.

Der eine reale CE-Ausfall erscheint an zwei Orten als getrennte lokale Fehler. Beide Knoten schützen lokal, und das Paket pendelt bis zum TTL-Ablauf. Der Draft warnt zusätzlich vor nutzloser Arbeit und möglicher Belastung des Backup-Pfads. Das ist ein Konstruktionsbeispiel, kein gemessener Produktionsvorfall; Häufigkeit und Wirkung sind nicht quantifiziert.

RFC 9791, Informational vom Juli 2025, abstrahiert genau dieses Problem. Abschnitt 2.1 sagt: Wenn ein Paket bereits durch FRR umgeleitet wurde, kann eine zweite FRR auf einem anderen Knoten zu Störung und Looping bis zum TTL-Ablauf führen. Die vorgeschlagene Richtung lautet, bereits umgeleitete Pakete per MPLS Network Action zu markieren, damit weitere FRR unterbleibt. Das ist ein Use Case, keine vollständige NFFRR-Spezifikation.

Die Markierung als delegiertes Veto

Technisch klingt „keine weitere FRR“ nach einem kleinen Zustandsbit. Operativ ist es eine weitreichende Entscheidung. Der erste Point of Local Repair setzt nicht nur ein Merkmal über die Vergangenheit des Pakets. Er beeinflusst die Handlungsfreiheit eines späteren Knotens: Wenn dort ein weiterer Fehler sichtbar wird, soll dieser Knoten gerade nicht die lokale Reparatur anwenden, die er ohne Markierung gewählt hätte.

Damit wird aus dem Paketmerkmal ein delegiertes Veto: Die schnelle lokale Ausweichentscheidung gilt als verbraucht. Das kann gemeinsame Kapazität schützen, aber ebenso absichtlichen Verlust erzeugen, wenn eine zweite Reparatur erfolgreich gewesen wäre.

Die Berechtigung zu diesem Veto hängt deshalb von vier Annahmeklassen ab. Erstens Topologie: Ist die erste Reparatur wirklich in einem Bereich, in dem eine zweite Umleitung zurückführen kann? Zweitens Fehlermodell: Handelt es sich um zwei unabhängige Fehler oder um zwei Beobachtungen desselben Ausfalls? Drittens Fähigkeiten: Verstehen die nachgelagerten Knoten die Markierung und behandeln sie sie konsistent? Viertens Vertrauen: Darf der markierende Knoten überhaupt eine Entscheidung treffen, die andere Knoten zum Verzicht auf Reparatur veranlasst?

RFC 5286 zeigt bereits für Loop-Free Alternates, dass Schutzabdeckung und Schleifenfreiheit von Topologie und angenommenem Fehlerszenario abhängen. Ein Alternate, der für einen Link-Ausfall sicher ist, kann unter einem umfassenderen Fehler anders wirken. RFC 7490 erweitert dieses Modell mit Remote LFA, bleibt aber ebenfalls an konkrete Erreichbarkeits- und Fehlerannahmen gebunden. NFFRR beseitigt diese Abhängigkeit nicht; es verschiebt vielmehr die Entscheidung, wann eine weitere Reparatur als zu riskant gilt, in ein explizites Signal.

Standardisierte Hülle, nicht standardisierte NFFRR-Aktion

Hier liegt die wichtigste Grenze gegen Überinterpretation. RFC 9789 ist das MNA-Framework. Es beschreibt unter anderem Scopes wie Hop-by-Hop, Ingress-to-Egress und Select und verlangt, dass konkrete Network Actions ihre Semantik präzisieren. RFC 9994, Proposed Standard vom Juni 2026, standardisiert die generische In-Stack-Codierung für MNA, die Platzierung von Network Action Sub-Stacks, Scopes und das Verhalten bei unbekannten Aktionen.

Für Pfade mit gemischten Fähigkeiten ist das zentral. Bei einer unbekannten Network Action bedeutet U=0: zur nächsten Aktion springen. U=1 bedeutet: Paket verwerfen; dafür soll ein lokaler Zähler geführt werden, eine rate-limitierte Meldung ist optional. RFC 9994 definiert NFFRR selbst nicht.

Auch die beiden spezielleren Entwürfe sind kein Einsatznachweis. draft-li-mpls-mna-nffrr-01 ist abgelaufen und nannte für NFFRR die Bitposition „TBA1“ sowie Hop-by-Hop- und Select-Scope. draft-kompella-mpls-nffrr-04 ist ebenfalls abgelaufen und diskutierte unter anderem ein spezielles Label sowie Capability-Signalisierung über mehrere Protokolle. Solche vorgeschlagenen Werte und Mechanismen sind weder aktuelle Zuweisungen noch Belege für Herstellerimplementierung oder Betrieb.

Am 20. September 2026 enthält das IANA-Register für MPLS Network Actions keinen NFFRR-Eintrag. Das Register führt die von RFC 9994 geschaffenen Kategorien und generischen Zuweisungen, aber keine NFFRR-Flag-Zuweisung. Daraus folgt weder, dass niemand experimentiert, noch dass NFFRR verworfen wäre. Es folgt nur: Eine aktuelle IANA-Zuweisung lässt sich daraus nicht belegen.

Falsch, fehlend, veraltet, gefälscht, missverstanden

Eine Markierung kann auf mehrere Arten scheitern. Ist sie falsch, wird eine zweite Reparatur blockiert, obwohl sie sicher und nützlich gewesen wäre. Fehlt sie, kann ein Paket erneut umgeleitet werden und in genau den Loop geraten, den der Mechanismus verhindern soll. Ist sie veraltet, kann sich die relevante Topologie oder Fehlerlage seit der Entscheidung verändert haben; ein früher berechtigtes Veto kann später unnötigen Verlust verursachen.

Ist sie gefälscht, wird aus Resilienzlogik ein Angriffshebel. Der Kompella-Draft nennt diesen Fall ausdrücklich: Ein bösartiger oder kompromittierter LSR könne NFFRR einfügen und damit eine FRR verhindern, die einen Fehler sonst hätte schützen können. Der Li-Draft formuliert allgemeiner, dass ein Angreifer im Forwarding Plane Daten einfügen, entfernen, verfälschen oder verändern kann.

Und wird die Markierung missverstanden, entstehen bei gemischten Fähigkeiten neue Grenzfälle. Ein Knoten, der die relevante Aktion nicht versteht, muss sich nach der generischen MNA-Regel richten. Überspringen kann die beabsichtigte Sperre wirkungslos machen; Verwerfen kann die Zustellung beenden, obwohl der Knoten die Semantik selbst nicht beurteilen kann. Deshalb ist „Capability vorhanden“ keine Nebensache, sondern Teil der Entscheidungskette.

Redaktioneller Vorschlag: ein FRR-Rückhaltebeleg

Für produktive Verantwortlichkeit würde ich, Daniel Kade, einen FRR-Rückhaltebeleg verlangen. Das ist ausdrücklich kein Erfordernis aus RFC 9791, RFC 9789 oder RFC 9994, sondern ein redaktioneller Vorschlag: ein prüfbarer Datensatz dafür, warum eine weitere lokale Reparatur unterdrückt werden durfte.

Er sollte mindestens enthalten:

  • Dienstklasse;
  • erste und zweite Fehlerbeobachtung;
  • ersten PLR und die gewählte Reparatur;
  • Topologieversion und angenommenes Fehlermodell;
  • Aktionsidentität, Scope, Einfügung und Stackposition;
  • Fähigkeitsnachweis der relevanten Knoten;
  • Herkunft der Markierung und Grenzfilter;
  • nachgelagerte Erkennung und endgültige Behandlung;
  • Zähler zu Aktion, Überlast und Verlust;
  • den Policy-Verantwortlichen sowie Prüf- und Ablaufauslöser.

Der Zweck ist, eine riskante Automationsentscheidung später rekonstruieren zu können: Wer setzte das Veto, auf welcher Netzsicht, mit welcher erwarteten Schutzwirkung, und was geschah tatsächlich?

Quellen